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Introduccion 


comienzo  de  internet,  ios  desarrolladores  Web  escribian  cada  una  de  las  paginas 
a mano.  Actualizar  un  sitio  significaba  editar  HTML;  un  “rediseno”  implicaba  rehacer 
cada  una  de  las  paginas,  una  a la  vez. 

Como  los  sitios  Web  crecieron  y se  hicieron  mas  ambiciosos,  rapidamente  se  hizo 
evidente  que  esta  situation  era  tediosa,  consumia  tiempo  y al  final  era  insostenible. 
Un  grupo  de  emprendedores  del  NCSA  (Centro  Nacional  de  Aplicaciones  para 
Supercomputadoras,  donde  se  desarrollo  el  Mosaic;  el  primer  navegador  Web 
grafico)  soluciono  este  problema  permitiendo  que  el  servidor  Web  invocara 
programas  externos  capaces  de  generar  HTML  dinamicamente.  Elios  llamaron  a este 
protocolo  “Puerta  de  Enlace  Comun”,  o CGI1,  y esto  cambio  internet  para  siempre. 

Ahora  es  dificil  imaginar  la  revelation  que  CGI  debe  haber  sido:  en  vez  de  tratar 
con  paginas  HTML  como  simples  archivos  del  disco,  CGI  te  permite  pensar  en 
paginas  como  recursos  generados  dinamicamente  bajo  demanda.  El  desarrollo  de 
CGI  hace  pensar  en  la  primera  generation  de  pagina  Web  dinamicas. 

Sin  embargo,  CGI  tiene  sus  problemas:  los  scripts  CGI  necesitan  contener  gran 
cantidad  de  codigo  repetitivo  que  los  hace  dificil  de  reutilizar,  asi  como  complicados 
de  entender  y escribir  para  los  desarrolladores  novatos. 

PHP  soluciono  varios  de  estos  problemas  y tomo  al  mundo  por  sorpresa  -ahora 
es,  por  lejos,  la  herramienta  mas  popular  usada  para  crear  sitios  Web  dinamicos,  y 
decenas  de  lenguajes  y entornos  similares  (ASP,  JSP,  etc.)  siguieron  de  cerca  el  diseno 
de  PHP.  La  mayor  innovation  de  PHP  es  que  es  facil  de  usar:  el  codigo  PHP  es  simple 
de  embeber  en  un  HTML  piano;  la  curva  de  aprendizaje  para  algunos  que  recien 
conocen  HTML  es  extremadamente  liana. 

Pero  PHP  tiene  sus  propios  problemas;  por  su  facilidad  de  uso,  alienta  a la 
production  de  codigo  mal  hecho.  Lo  que  es  peor,  PHP  hace  poco  para  proteger  a los 
programadores  en  cuanto  a vulnerabilidades  de  seguridad,  por  lo  que  muchos 
desarrolladores  de  PHP  se  encontraron  con  que  tenian  que  aprender  sobre  seguridad 
cuando  ya  era  demasiado  tarde. 

Estas  y otras  frustraciones  similares,  condujeron  directamente  al  desarrollo  de  los 
actuales  frameworks  de  desarrollo  Web  de  “tercera  generation”.  Estos  frameworks 
Django  y Ruby  on  Rails  - parecen  ser  muy  populares  en  estos  dias  - reconocen  que  la 
importancia  de  la  Web  se  ha  intensificado  en  los  ultimos  tiempos.  Con  esta  nueva 
explosion  del  desarrollo  Web  comienza  otro  incremento  en  la  ambition;  se  espera 
que  los  desarrolladores  Web  hagan  mas  y mas  cada  dia. 

1 N.  del  T.:  Common  Gateway  Interface 
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Django  fue  desarrollado  para  satisfacer  esas  nuevas  ambiciones.  Django  te 
permite  construir  en  profundidad,  de  forma  dinamica,  sitios  interesantes  en  un 
tiempo  extremadamente  corto.  Django  esta  disenado  para  hacer  foco  en  la  diversion, 
en  las  partes  interesantes  de  tu  trabajo,  al  mismo  tiempo  que  alivia  el  dolor  de  las 
partes  repetitivas.  Al  hacerlo,  proporciona  abstracciones  de  alto  nivel  a patrones 
comunes  del  desarrollo  Web,  agrega  atajos  para  tareas  frecuentes  de  programacion  y 
claras  convenciones  sobre  como  resolver  problemas.  Al  mismo  tiempo,  intenta 
mantenerse  fuera  de  tu  camino,  dejando  que  trabajes  fuera  del  alcance  del 
framework  cuando  sea  necesario.  Escribimos  este  libro  porque  creemos  firmemente 
que  Django  mejora  el  desarrollo  Web.  Esta  disenado  para  poner  rapidamente  en 
movimiento  tu  propio  proyecto  de  Django,  en  ultima  instancia  aprenderas  todo  lo 
que  necesites  saber  para  producir  el  diseno,  desarrollo  y despliegue  de  sitios 
satisfactorios  y de  los  cuales  te  sientas  orgulloso. 

Estamos  extremadamente  interesados  en  la  retroalimentacion.  La  version  online 
de  este  libro  te  permite  dejar  un  comentario  en  cualquier  parte  del  libro  y discutir  con 
otros  lectores.  Hacemos  cuanto  podemos  para  leer  todos  los  comentarios  posteados 
alii  y responder  tantos  como  nos  sea  posible.  Si  prefieres  utilizar  correo  electronico, 
por  favor  envianos  unas  lineas  (en  ingles)  a (?)  feedback@djangobook.com.  De 
cualquier  modo,  jnos  encantaria  escucharte!  Nos  alegra  que  estes  aqui,  y esperamos 
que  encuentres  a Django  tan  emocionante,  divertido  y util  como  nosotros. 


PARTE  1 


Comenzando 


CAPITULO  1 


Introduccion  a Django 


Este  libro  es  sobre  Django,  un  framework  de  desarrollo  Web  que  ahorra  tiempo  y 
hace  que  el  desarrollo  Web  sea  divertido.  Utilizando  Django  puedes  crear  y mantener 
aplicaciones  Web  de  alta  calidad  con  un  minirno  esfuerzo. 

En  el  mejor  de  los  casos,  el  desarrollo  Web  es  un  acto  entretenido  y creativo;  en  el 
peor,  puede  ser  una  molestia  repetitiva  y frustrante.  Django  te  permite  enfocarte  en  la 
parte  creativa  - la  parte  divertida  de  tus  aplicaciones  Web  al  mismo  tiempo  que 
mitiga  el  esfuerzo  de  las  partes  repetitivas.  De  esta  forma,  provee  un  alto  nivel  de 
abstraction  de  patrones  comunes  en  el  desarrollo  Web,  atajos  para  tareas  frecuentes 
de  programacion  y convenciones  claras  sobre  como  solucionar  problemas.  Al  mismo 
tiempo,  Django  intenta  no  entrometerse,  dejandote  trabajar  fuera  del  ambito  del 
framework  segun  sea  necesario. 

El  objetivo  de  este  libro  es  convertirte  en  un  experto  de  Django.  Por  lo  que  el 
enfoque  es  doble,  primero,  explicamos  en  profundidad  lo  que  hace  Django,  y como 
crear  aplicaciones  Web  con  el,  segundo,  discutiremos  conceptos  de  alto  nivel  cuando 
se  considere  apropiado,  contestando  la  pregunta  jComo  puedo  aplicar  estas 
herramientas  de  forma  efectiva  en  mis  propios  proyectos?  Al  leer  este  libro, 
aprenderas  las  habilidades  necesarias  para  desarrollar  sitios  Web  conectados  a una 
base  de  datos,  poderosos,  de  forma  rapida,  con  codigo  limpio  y de  facil 
mantenimiento. 

En  este  capitulo  presentamos  una  vision  general  sobre  Django. 


^Que  es  un  Framework  Web? 

Django  es  un  miembro  importante  de  una  nueva  generation  de  frameworks  Web. 
ePero  que  significa  este  termino  exactamente? 

Para  contestar  esa  pregunta,  consideremos  el  diseno  de  una  aplicacion  Web 
escrita  en  Python,  sin  usar  un  framework.  Una  de  las  formas  mas  simples  y directas 
para  construir  una  aplicacion  Web  desde  cero  en  python,  es  usando  el  estandar 
Common  Gateway  Interface  (CGI),  una  tecnica  muy  popular  para  escribir 
aplicaciones  Web  alrededor  del  ano  1998.  Esta  es  una  explication  de  alto  nivel  sobre 
como  trabaja.  Solo  crea  un  script  Python,  que  produzca  HTML,  guarda  el  script  en  el 
servidor  Web  con  la  extension  .cgi  y visita  la  pagina  con  un  navegador  Web.  Eso  jEso 
todo! 

Por  ejemplo,  aqui  hay  un  sencillo  script  CGI,  escrito  en  python  2.x,  que  muestra 
los  diez  ultimos  libros  publicados  en  una  base  de  datos.  No  te  preocupes  por  los 
detalles  de  la  sintaxis;  solo  observa  las  cosas  basicas  que  hace: 
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#!/usr/bin/env  python 

import  MySQLdb 

print  "Content-Type:  text/html\n" 
print 

print  "<html><head><title>Libros</title></head>" 

print  "<body>" 

print  "<hl>Libros</hl>" 

print  "<ul>" 

connection  = MySQLdb. connect(user='yo',  passwd='dejamentrar',  db='books.db') 
cursor  = connection. cursor() 

cursor. execute("SELECT  nombre  FROM  libros  ORDER  BY  fecha  DESC 
LIMIT  10") 

for  row  in  cursor. fetchall(): 

print  "<li>%s</li>"  % row[Q] 

print  "</ul>" 

print  "</bodyx/html>" 

connection. closeQ 


Este  codigo  es  sencillo  de  entender.  Primero  imprime  una  lfnea  de  “Content- 
Type”,  seguido  de  una  lfnea  en  bianco,  tal  como  requiere  CGI.  Imprime  el  HTML 
introductorio,  se  conecta  a la  base  de  datos  y ejecuta  una  consulta  que  obtiene  los 
diez  ultimos  libros  publicados,  de  una  tabla  llamada  libros.  Hace  un  bucle  sobre  esos 
libros  y genera  una  lista  HTML  desordenada.  Linalmente  imprime  el  codigo  para 
cerrar  el  HTML  y cierra  la  conexion  con  la  base  de  datos. 

Con  una  pagina  unica  y poco  dinamica  como  esta,  el  enfoque  desde  cero  no  es 
necesariamente  malo.  Por  un  lado,  este  codigo  es  sencillo  de  comprender  - incluso 
un  desarrollador  novato  puede  leer  estas  lineas  de  Python  y entender  todo  lo  que 
hace  el  script,  de  principio  a fin.  No  hay  mas  nada  que  aprender;  no  hay  mas  codigo 
para  leer.  Tambien  es  sencillo  de  utilizar:  solo  guarda  este  codigo  en  un  archivo 
llamado  ultimoslibros.cgi,  sube  ese  archivo  a un  servidor  Web  y visita  esa  pagina  con 
un  navegador. 

Sin  embargo  a medida  que  una  aplicacion  Web  crece  mas  alia  de  lo  trivial,  este 
enfoque  se  desmorona  y te  enfrentas  a una  serie  de  problemas: 

■ ^Que  sucede  cuando  multiples  paginas  necesitan  conectarse  a la  base  de 
datos?  Seguro  que  ese  codigo  de  conexion  a la  base  de  datos  no  deberfa  estar 
duplicado  en  cada  uno  de  los  scripts  CGI,  asi  que  la  forma  pragmatica  de 
hacerlo  seria  refactorizarlo  en  una  funcion  compartida. 

■ ^Deberfa  un  desarrollador  realmente  tener  que  preocuparse  por  imprimir  la 
llnea  de  “Content-Type”  y acordarse  de  cerrar  la  conexion  con  la  base  de 
datos?  Este  tipo  de  codigo  repetitivo  reduce  la  productividad  del  programador 
e introduce  la  oportunidad  para  que  se  cometan  errores.  Estas  tareas  de 
configuration  y cierre  estarian  mejor  manejadas  por  una  infraestructura 
comun. 

■ ^Que  sucede  cuando  este  codigo  es  reutilizado  en  multiples  entornos,  cada 
uno  con  una  base  de  datos  y contrasenas  diferentes?  En  ese  punto,  se  vuelve 
esencial  alguna  configuration  especiflca  del  entorno. 
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■ iQue  sucede  cuando  un  disenador  Web  que  no  tiene  experiencia 
programando  en  Python  desea  redisenar  la  pagina?  Lo  ideal  seria  que  la  logica 
de  la  pagina  - la  busqueda  de  libros  en  la  base  de  datos  - este  separada  del 
codigo  HTML  de  la  pagina,  de  modo  que  el  disenador  pueda  hacer 
modificaciones  sin  afectar  la  busqueda. 

Precisamente  estos  son  los  problemas  que  un  framework  Web  intenta  resolver.  Un 
framework  Web  provee  una  infraestructura  de  programacion  para  tus  aplicaciones, 
para  que  puedas  concentrarte  en  escribir  codigo  limpio  y de  facil  mantenimiento  sin 
tener  que  reinventar  la  rueda.  En  resumidas  cuentas,  eso  es  lo  que  hace  Django. 

El  patron  de  diseno  MVC 

Comencemos  con  un  ejemplo  rapido,  que  demuestra  la  diferencia  entre  el  enfoque 
anterior  y el  empleado  al  usar  un  framework  Web.  Asi  es  como  se  podria  escribir  el 
codigo  CGI  anterior  usando  Django: 


models .py 


from  django.db  import  models 
'"Las  tablas  de  la  base  de  datos"' 

class  Libro(models. Model): 

nombre  = models.  CharField(max_length=50) 
fecha  = models. DateFieldQ 


views . py 


from  django. shortcuts  import  render_to_response 
from  models  import  Libro 

def  ultimosjibros(request): 

"'La  parte  logica'" 

listajibros  = Libro. objects. order_by(-fecha')[:  10] 

return  render_to_response('ultimos-libros.html',  {'listajibros':  listajibros}) 


urls .py 


from  django. conf.urls  import  url 
import  views 

# La  configuracion  de  la  URL 

urlpatterns  = [ 

url(r'AultimosJibros/$',  views. ultimosjibros), 

] 


ultimos  libros.html 


{#  La  plantilla  #} 

<html><head><title>Libros</titlex/head> 

<body> 

<hl>Libros</hl> 

<ul> 

{%  for  libro  in  listajibros  %} 

<li>{{  libro. nombre  }}</li> 

{%  endfor  %} 

</ul> 

</bodyx/html> 
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No  es  todavia  necesario  preocuparse  por  los  detalles  sobre  como  funciona  esto  - 
tan  solo  queremos  que  te  acostumbres  al  diseno  general.  Lo  que  hay  que  notar 
principalmente  en  este  ejemplo,  son  las  cuestiones  de  separation : 

• El  archivo  models.py  contiene  una  description  de  la  tabla  de  la  base  de  datos, 
como  una  clase  Python.  A esto  se  lo  llama  el  modelo.  Usando  esta  clase  se 
pueden  crear,  buscar,  actualizar  y borrar  entradas  de  tu  base  de  datos  usando 
solo  codigo  Python  en  lugar  de  escribir  declaraciones  SQL  repetitivas. 


• El  archivo  views.py  contiene  la  logica  de  la  pagina,  en  la  funcion 
ullimosJibrosO  . A esta  funcion  se  la  denomina  vista. 

• El  archivo  urls.py  especifica  que  vista  es  llamada  segun  el  patron  URL.  En  este 
caso,  la  URL  / ultimo  sjibros/  sera  manejada  por  la  funcion  ullimosJibrosO. 
En  otras  palabras,  si  el  nombre  de  nuestro  dominio  es  example.com,  cualquier 
visita  a la  URL  http://example.com/ultimosJibros/  llamara  a la  funcion 
ultimosJibros(). 

• El  archivo  ultimosJibros.html  es  una  plantilla  HTML  especial,  que  describe 
el  diseno  de  la  pagina.  Usa  el  lenguaje  de  plantillas  de  Django,  con 
declaraciones  basicas  y logicas  por  ejemplo:  {%  for  libro  in  listajibros  %}. 

Tomadas  en  su  conjunto,  estas  piezas  se  aproximan  al  patron  de  diseno  Modelo- 
Vista-Controlador  (MVC).  Dicho  de  manera  mas  facil,  MVC  define  una  forma  de 
desarrollar  software  en  la  que  el  codigo  para  deflnir  y acceder  a los  datos  (el  modelo) 
esta  separado  del  pedido  logico  de  asignacion  de  ruta  (el  controlador),  que  a su  vez 
esta  separado  de  la  interfaz  del  usuario  (la  vista). 

Una  ventaja  clave  de  este  enfoque  es  que  los  componentes  tienen  un  acoplamiento 
debit  entre  si.  Eso  significa  que  cada  pieza  de  la  aplicacion  Web  que  funciona  sobre 
Django  tiene  un  unico  proposito  clave,  que  puede  ser  modificado 
independientemente  sin  afectar  las  otras  piezas.  Por  ejemplo,  un  desarrollador  puede 
cambiar  la  URL  de  cierta  parte  de  la  aplicacion  sin  afectar  la  implementation 
subyacente.  Un  disenador  puede  cambiar  el  HTML  de  una  pagina  sin  tener  que  tocar 
el  codigo  Python  que  la  renderiza.  Un  administrador  de  base  de  datos  puede 
renombrar  una  tabla  de  la  base  de  datos  y especiflcar  el  cambio  en  un  unico  lugar,  en 
lugar  de  tener  que  buscar  y reemplazar  en  varios  archivos. 

En  este  libro,  cada  componente  tiene  su  propio  capitulo.  Por  ejemplo,  el  c apitulo3 
trata  sobre  las  vistas,  el  capitulo4  sobre  las  plantillas  y el  capitulo5 sobre  los  modelos. 

Historia  de  Django 

Antes  de  empezar  a escribir  codigo,  deberiamos  tomarnos  un  momento  para  explicar 
la  historia  de  Django.  Y para  mostrar  como  se  hacen  las  cosas  sin  usar  atajos,  esto  nos 
ayudara  a entenderlos  mejor.  Es  util  entender  por  que  se  creo  el  framework,  ya  que  el 
conocimiento  de  la  historia  pone  en  contexto  la  razon  por  la  cual  Django  trabaja  de  la 
forma  en  que  lo  hace. 

Si  has  estado  creando  aplicaciones  Web  por  un  tiempo,  probablemente  estes 
familiarizado  con  los  problemas  del  ejemplo  CGI  presentado  con  anterioridad.  El 
camino  clasico  de  un  desarrollador  Web  es  algo  como  esto: 

1.  Escribir  una  aplicacion  Web  desde  cero. 

2.  Escribir  otra  aplicacion  Web  desde  cero. 

3.  Darse  cuenta  de  que  la  aplicacion  del  paso,  1 tiene  muchas  cosas  en  comun 
con  la  aplicacion  del  paso  2. 
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4.  Refactorizar  el  codigo  para  que  la  aplicacion  1,  comparta  codigo  con  la 
aplicacion  2. 

5.  Repetir  los  pasos  2-4  varias  veces. 

6.  Darse  cuenta  de  que  acabamos  de  inventar  un  framework. 

As!  es  precisamente  como  surgio  Django. 

Django  nacio  naturalmente  de  aplicaciones  de  la  vida  real  escritas  por  un  equipo 
de  desarrolladores  Web  en  Lawrence,  Kansas.  Nacio  en  el  otono  boreal  de  2003, 
cuando  los  programadores  Web  del  diario  Lawrence  Journal-World,  Adrian  Holovaty 
y Simon  Willison,  comenzaron  a usar  Python  para  crear  sus  aplicaciones. 

El  equipo  de  The  World  Online,  responsable  de  la  production  y mantenimiento 
de  varios  sitios  locales  de  noticias,  prosperaban  en  un  entorno  de  desarrollo  dictado 
por  las  fechas  llmite  del  periodismo.  Para  los  sitios  -incluidos  LJWorld.com, 
Lawrence.com  y KUsports.com  los  periodistas  (y  los  directivos)  exigian  que  se 
agregaran  nuevas  caracteristicas  y que  aplicaciones  enteras  se  crearan  a una 
velocidad  vertiginosa,  a menudo  con  solo  dias  u horas  de  preaviso.  Es  asi  que  Adrian 
y Simon  desarrollaron  por  necesidad  un  framework  de  desarrollo  Web  que  les 
ahorrara  tiempo  - era  la  unica  forma  en  que  podian  crear  aplicaciones  mantenibles 
en  tan  poco  tiempo. 

En  el  verano  de  2005,  luego  de  haber  desarrollado  este  framework  hasta  el  punto 
en  que  estaba  haciendo  funcionar  la  mayorfa  de  los  sitios  de  World  Online,  el  equipo 
de  World  Online,  que  ahora  incluia  a Jacob  Kaplan-Moss,  decidio  liberar  el 
framework  como  software  de  codigo  abierto.  Lo  liberaron  en  julio  de  2005  y lo 
11am aron  Django,  por  el  guitarrista  de  jazz  “Django  Reinhardt”. 

Hoy  en  dia,  Django  es  un  proyecto  estable  y maduro,  de  codigo  abierto  con  cientos 
de  miles  de  colaboradores  y usuarios  de  todo  el  mundo.  Dos  de  los  desarrolladores 
originales  de  Worl  Online  (“Los  benevolentes  dictadores  vitalicios”  Adrian  y Jacob) 
siguen  aportando  una  guia  centralizada  para  el  crecimiento  del  framework,  por  lo 
que  es  mas  un  equipo  de  colaboracion  comunitario. 

Esta  historia  es  relevante  porque  ayuda  a explicar  dos  cuestiones  clave.  La  primera 
es  el  “punto  dulce”  de  Django.  Debido  a que  Django  nacio  en  un  entorno  de  noticias, 
ofrece  varias  caracteristicas  (en  particular  la  interfaz  administrativa,  tratada  en  el 
capitulo  6,  que  son  particularmente  apropiadas  para  sitios  de  “contenido”  - sitios 
como  eBay,  craigslist.org  y washingtonpost.com  que  ofrecen  information  basada  en 
bases  de  datos.  (De  todas  formas,  no  dejes  que  eso  te  quite  las  ganas  a pesar  de  que 
Django  es  particularmente  bueno  para  desarrollar  esa  clase  de  sitios,  eso  no  significa 
que  no  sea  una  herramienta  efectiva  para  crear  cualquier  tipo  de  sitio  Web  dinamico. 
Existe  una  gran  diferencia  entre  ser  particularmente  efectivo  para  algo  y no  ser 
particularmente  efectivo  para  otras  cosas). 

La  segunda  cuestion  a resaltar  es  como  los  origenes  de  Django  le  han  dado  forma  a 
la  cultura  de  su  comunidad  de  codigo  abierto.  Debido  a que  Django  fue  extraido  de 
codigo  de  la  vida  real,  en  lugar  de  ser  un  ejercicio  academico  o un  producto 
comercial,  esta  especialmente  enfocado  en  resolver  problemas  de  desarrollo  Web  con 
los  que  los  desarrolladores  de  Django  se  han  encontrado  - y con  los  que  continuan 
encontrandose.  Como  resultado  de  eso,  Django  es  continuamente  mejorado.  Los 
desarrolladores  del  framework  tienen  un  alto  grado  de  interes  en  asegurarse  de  que 
Django  les  ahorre  tiempo  a los  desarrolladores,  produzca  aplicaciones  que  sean 
faciles  de  mantener  y rindan  bajo  mucha  carga.  Aunque  existen  otras  razones,  los 
desarrolladores  estan  motivados  por  sus  propios  deseos  egoistas  de  ahorrarse  tiempo 
a ellos  mismos  y disfrutar  de  sus  trabajos. 
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Como  leer  este  libro 

A1  escribir  este  libro,  tratamos  de  alcanzar  un  balance  entre  legibilidad  y referencia, 
con  una  tendencia  a la  legibilidad.  Nuestro  objetivo,  como  se  menciono 
anteriormente,  es  hacerte  un  experto  en  Django,  y creemos  que  la  mejor  manera  de 
ensenar  es  a traves  de  la  prosa  y numerosos  ejemplos,  en  vez  de  proveer  un 
exhaustivo  pero  inutil  catalogo  de  las  caracteristicas  de  Django  (Como  alguien  dijo 
una  vez,  no  puedes  esperar  ensenarle  a alguien  como  hablar  simplemente 
ensenandole  el  alfabeto). 

Con  esto  en  mente,  te  recomendamos  que  leas  los  capitulos  del  1 al  7 en  orden. 
Elios  forman  los  fundamentos  basicos  sobre  la  forma  en  que  se  usa  Django;  una  vez 
que  los  hayas  leido,  seras  capaz  de  construir  sitios  Web  que  funcionen  sobre  Django. 
Los  capitulos  7 al  12,  muestran  caracteristica  avanzadas  del  framework,  los  capitulos 
restantes,  estan  enfocados  en  caracteristicas  especificas  de  Django  y pueden  ser 
leidos  en  cualquier  orden. 

Los  apendices  son  para  referencia.  Que  junto  a la  documentation  libre  disponible  en 
http://www.djangoproject.com/,  son  probablemente  los  documentos  que  tendras 
que  leer  de  vez  en  cuando,  para  recordar  la  sintaxis  o buscar  un  resumen  rapido  de  lo 
que  hace  ciertas  partes  de  Django,  no  explicadas  aqui. 


Conocimientos  Requeridos 

Los  lectores  de  este  libro  deben  comprender  las  bases  de  la  programacion  orientada  a 
objetos  e imperativa:  estructuras  de  control  (por  ejemplo:  if,  while,  for)),  estructuras 
de  datos  (listas,  hashes/diccionarios),  variables,  clases  y objetos. 

La  experiencia  en  desarrollo  Web  es,  como  podras  esperar,  muy  util,  pero  no  es 
requisito  para  leer  este  libro.  A lo  largo  del  mismo,  tratamos  de  promover  las  mejores 
practicas  en  desarrollo  Web  para  los  lectores  a los  que  les  falta  este  tipo  de 
experiencia. 

Conocimientos  de  Python  requeridos 

En  esencia,  Django  es  sencillamente  una  coleccion  de  bibliotecas  escritas  en  el 
lenguaje  de  programacion  Python.  Para  desarrollar  un  sitio  usando  Django  escribes 
codigo  Python  que  utiliza  esas  bibliotecas.  Aprender  Django,  entonces,  es  solo 
cuestion  de  aprender  a programar  en  Python  y comprender  como  funcionan  las 
bibliotecas  de  Django. 

Si  tienes  experiencia  programando  en  Python,  no  deberias  tener  problema  en 
meterte  de  lleno.  En  conjunto,  el  codigo  Django  no  produce  “magia  negra”  (es  decir, 
trucos  de  programacion  cuya  implementation  es  dificil  de  explicar  o entender).  Para 
ti,  aprender  Django  sera  solo  cuestion  de  aprender  las  convenciones  y APIs  de 
Django. 

Si  no  tienes  experiencia  programando  en  Python,  te  espera  una  grata  sorpresa.  Es 
facil  de  aprender  y muy  divertido  de  usar.  A pesar  de  que  este  libro  no  incluye  un 
tutorial  completo  de  Python,  si  hace  hincapie  en  las  caracteristicas  y funcionalidades 
de  Python  cuando  se  considera  apropiado,  particularmente  cuando  el  codigo  no 
cobra  sentido  de  inmediato.  Aun  asi,  recomendamos  leer  el  tutorial  oficial  de  Python, 
disponible  en  http://pyspanishdoc.sourceforge.net/tut/tut.html  o su  version  mas 
reciente  en  ingles  en  http://docs.python.org/tut/.  Tambien  recomendamos  el  libro 
libre  y gratuito  de  Mark  Pilgrim  Inmersion  en  Python,  disponible  en 
http://es.diveintopython.org/  ypublicado  en  ingles  en  papel  por  Apress. 
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Version  requerida  de  Django 

Este  libro  cub  re  la  version  1.8  y superior. 

El  equipo  de  desarrolladores  de  Django,  trata  en  la  medida  de  lo  posible  de 
mantener  compatibilidad  con  versiones  anteriores,  sin  embargo  ocasionalmente,  se 
introducen  algunos  cambios  drasticos  e incompatibles  con  versiones  anteriores.  En 
cada  lanzamiento  estos  cambios  son  cubiertos  en  las  notas  del  lanzamiento,  que  se 
pueden  encontrar  en:  https://docs.djangoproject.eom/en/dev/releases/2.X 

Nuevas  caracteristicas  de  Django 

Tal  como  mencionamos  anteriormente,  Django  es  mejorado  con  frecuencia,  y 
probablemente  tendra  un  gran  numero  de  nuevas  -e  incluso  esenciales 
caracteristicas  para  cuando  este  libro  sea  publicado.  Por  ese  motivo,  nuestro  objetivo 
como  autores  de  este  libro  es  doble: 

• Asegurarnos  que  este  libro  sea  “a  prueba  de  tiempo”  tanto  como  nos  sea 
posible,  para  que  cualquier  cosa  que  leas  aqui  todavia  sea  relevante  en  futuras 
versiones  de  Django. 

• Actualizar  este  libro  continuamente  en  el  sitio  Web  en  ingles, 
http://www.djangobook.com/,  para  que  puedas  acceder  a la  mejor  y mas 
reciente  documentation  tan  pronto  como  la  escribamos. 

Si  quieres  implementar  con  Django  algo  que  no  esta  explicado  en  este  libro,  revisa 
la  version  mas  reciente  de  este  libro  en  el  sitio  Web  y tambien  revisa  la 
documentation  oficial  de  Django,  para  obtener  detalles  mas  completos. 


Obtener  ayuda 

Para  obtener  ayuda  con  cualquier  aspecto  de  Django  - desde  instalacion  y diseno  de 
aplicaciones,  hasta  diseno  de  bases  de  datos  e implementaciones  sientete  libre  de 
hacer  preguntas  online. 

En  la  lista  de  correo  de  usuarios  de  Django  (en  ingles)  se  juntan  miles  de  usuarios 
para  preguntar  y responder  dudas.  Suscribete  gratuitamente  en 
http://www.djangoproject.eom/r/django-users. 

El  canal  de  IRC  de  Django  donde  los  usuarios  de  Django  se  juntan  a chatear  y se 
ayudan  unos  a otros  en  tiempo  real.  Unete  a la  diversion  en  #django  (ingles)  o 
#django-es  (espanol)  en  la  red  de  IRC  Freenode. 

^Que  sigue? 

A continuation,  en  el  capitulo  2 utilizaremos  Django,  explicaremos  su  instalacion  y la 
configuration  inicial. 


CAPITULO  2 


Empezando 


Instalar  Django  es  un  proceso  que  consta  de  varios  pasos,  debido  a las  multiples 
partes  moviles  de  las  que  constan  los  entornos  modernos  de  desarrollo  Web.  En  este 
capitulo  se  explican  las  situaciones  mas  comunes  de  instalacion  del  framework  y 
algunas  de  sus  dependencias. 

Debido  a que  Django  es  “solo”  codigo  Python,  se  puede  utilizar  en  cualquier 
sistema  que  corra  Python,  jincluyendo  algunos  telefonos  celulares!  Por  lo  que  este 
capitulo  cubre  los  escenarios  mas  comunes  para  su  instalacion.  Asumiremos  que 
quieres  instalarlo  en  una  computadora  de  escritorio/ laptop  o en  un  servidor. 

Mas  adelante,  en  el  capitulol2ie  mostraremos,  como  desplegar  Django  en  un  sitio 
de  produccion. 


Instalar  Python 

Django  esta  escrito  totalmente  en  codigo  Python,  por  lo  tanto  lo  primero  que 
necesitas  para  usarlo,  es  asegurarte  de  que  tienes  instalada  una  version  apropiada  de 
Python. 

El  nucleo  del  framework  en  la  version  1.4  trabaja  con  cualquier  version  de  Python 
superior  a la  2.5  y 2.7.  Django  1.5  y Django  1.6,  requieren  Python  2.6.5  como  minimo. 
A partir  de  este  lanzamiento  Python  3 es  oficialmente  soportado.  Recomendamos 
ampliamente  utilizar  las  ultimas  y menores  versiones  de  cada  lanzamiento  de  Python 
soportados  (2.7.X,  3.2.X,  3.3.X  y 3.4.X).  Toma  en  cuenta  que  Django  1.6  es  la  ultima 
version  que  dara  soporte  a Python  2.6;  ya  que  requiere  como  minimo  Python  2.7. 

Si  no  estas  seguro,  sobre  que  version  de  Python  instalar  y tienes  completa  libertad 
para  decidir,  busca  una  de  las  ultimas  versiones  de  la  serie  2,  en  especial  la  version  3 o 
superior.  Aunque  Django  trabaja  bien  con  cualquiera  de  estas  versiones,  las  ultimas 
versiones  de  la  serie  3 proveen  mejores  caracteristicas. 


Django  y Python3 

A partir  de  la  version  1.7,  Django  admite  oficialmente  Python  3,  3.2,  3.3,  y 3.4.  Por  lo 
que  si  estas  empezando  un  nuevo  proyecto  y las  dependencias  que  piensas  usar, 
trabajan  bien  en  Python  3 deberfas  usar  Python  3.  De  cualquier  forma  si  no  la  haces, 
no  deberias  tener  ningun  problema  con  el  funcionamiento  de  tu  codigo. 

A partir  de  Django  1.6,  el  soporte  para  Python  3 es  considerado  estable  y puede  ser 
usado  de  forma  segura  en  produccion.  Es  por  ello  que  la  comunidad  esta  empezando 
a migrar  paquetes  de  terceros  y aplicaciones  a Python  3,  por  lo  que  es  una  buena  idea 
empezar  a usarlo,  ya  que  es  mas  sencillo  escribir  codigo  para  Python  3 y luego 
hacerlo  compatible  con  la  serie  2,  que  viceversa. 
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Las  nuevas  versiones  de  Python,  de  la  serie  3 son  mas  rapidas  y contienen  mas 
caracterfsticas  que  pueden  ser  muy  utiles  en  tus  proyectos  Django,  sin  embargo  si 
quieres  usar  una  version  en  especifico,  toma  en  cuenta  la  siguiente  tabla,  para  usar 
una  version  de  Python  adecuada  a la  version  de  Django  que  quieras  usar: 


Version  Django  Version  Python 


1.4  2.5,  2.6,  2.7 

1.5  2.6,  2.7  y 3.2,  3.3  (experimental) 

1.6  2.6,  2.7  y 3.2,  3.3 

1.7  2.7  y 3.2,  3.3,  3.4 

1.8  2.7  y 3.2,  3.3,  3.4 

1.9  2.7  y 3.2,  3.3,  3.4 

Tabla  2.1  Compatibilidad  entre  Python  y Django 


Instalacion 

Si  estas  usando  Linux  o Mac  OS  X probablemente  ya  tienes  instalada  alguna  version 
de  python  o dos  (Python  2.7  y Python3).  Escribe  python  o python3  en  una  terminal.  Si 
ves  algo  asi,  Python  esta  instalado: 

Python  3.4.0  (default,  Apr  11  2014,  13:05:18) 

[GCC  4.8.2]  on  linux 

Type  "help",  "copyright",  "credits"  or  "license"  for  more  information. 

»> 

Si  ves  un  error  como:  “command  not  found”  u “orden  no  encontrada”,  necesitas 
primero  bajar  e instalar  Python.  Para  empezar  puedes  encontrar  instrucciones  mas 
detalladas  en  la  pagina  de  descargas  oficial  de  Python,  disponible  online  en: 

® http://www.python.org/download/.  La  instalacion  es  rapida  y facil. 


Instalar  Django 

En  cualquier  momenta,  puedes  disponer  de  dos  versiones  distintas  de  Django: 

1.  El  lanzamiento  oficial  mas  reciente. 

2.  La  version  de  desarrollo. 

La  version  que  decidas  instalar  dependera  de  tus  prioridades.  Si  quieres  una 
version  estable,  probada  y lista  para  production,  instala  la  primera  option,  sin 
embargo  si  quieres  obtener  las  ultimas  y mejores  caracteristicas  y si  tal  vez  te  gustarra 
contribuir  con  Django  mismo,  usa  la  segunda  option  si  no  te  importa  mucho  la 
estabilidad. 

Nosotros  recomendamos  encarecidamente  usar  la  version  oficial,  pero  siempre  es 
importante  conocer  que  existe  una  version  de  desarrollo,  ya  que  como  se  menciona 
en  la  documentation,  esta  esta  disponible  para  cualquier  miembro  de  la  comunidad 
de  forma  libre. 

En  esta  section  explicaremos  algunas  opciones  de  instalacion:  instalar  un 
lanzamiento  oficial,  ya  sea  manualmente  o usando  pip  y explicaremos  la  forma  de 
instalar  la  version  de  desarrollo,  desde  el  repositorio  oficial  Git. 
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Instalar  un  lanzamiento  oficial 

Los  lanzamientos  oficiales  tienen  un  numero  de  version,  tal  como  1.7,  1.8  o 1.9,  la 
ultima  version  siempre  esta  disponible  en  la  pagina  de  descargas  del  proyecto  en: 

® http://www.djangoproject.com/download/. 

Si  estas  usando  alguna  distribucion  de  Linux,  la  mayoria  incluye  un  paquete  de 
Django,  por  lo  que  siempre  es  buena  idea  usar  la  version  que  se  distribuye  para  tu 
plataforma  e instalar  Django  con  el  gestor  de  paquetes  predeterminado.  De  esta 
forma  la  instalacion  no  traera  problemas  de  seguridad  al  resto  del  sistema  de 
paquetes,  actualizando  paquetes  de  forma  innecesaria,  ademas  los  gestores  se 
encargan  automaticamente  de  instalar  las  dependencias  necesarias  (como  los 
conectores  para  la  base  de  datos). 

Si  no  tienes  acceso  a una  version  pre-empaquetada,  puedes  descargar  e instalar  el 
framework  manualmente.  Para  hacerlo  primero  descarga  el  tarball,  que  se  llamara 
algo  asi  como  Django-version.tar.gz  (No  importa  cual  sea  el  directorio  local  que  elijas 
para  la  descarga,  ya  que  el  proceso  de  instalacion  se  encargara  de  colocar  Django  en 
el  lugar  correcto).  Descomprimelo  con  alguna  utilidad  como:  tar  xzvf  Django -.tar.gz, 
cambiate  al  directorio  recien  creado  con:  cd  Django-  y usa  el  comando:  setup. py 
install  o python  setup.py  install,  tal  y como  instalarias  cualquier  otra  libreria  Python 
(No  olvides  usar  sudo  o privilegios  de  administrador). 

En  sistemas  tipo  Unix,  esta  es  la  forma  en  que  se  ve  el  proceso: 

1.  tar  xzvf  Django-2. 0.tar.gz 

2.  cd  Django-* 

3.  sudo  python  setup.py  install 

En  Windows,  recomendamos  usar  7-Zip  (http:/ /www.djangoproject.com/r/7zip/) 

para  manejar  archivos  comprimidos  de  todo  tipo,  incluyendo  .tar.gz.  Una  vez  que  has 
descomprimido  el  archivo,  ejecuta  un  shell  de  comandos,  con  privilegios  de 
administrador  y ejecuta  el  siguiente  comando  desde  el  directorio  que  empieza  con 
Django-: 

python  setup.py  install 

Si  eres  algo  curioso,  te  daras  cuenta  que  la  instalacion  de  Django,  lo  que  hace  es 
instalarse  en  un  directorio  llamado  site-packages  -Un  directorio  de  paquetes,  donde 
Python  busca  las  librerfas  de  terceros.  Usualmente  esta  ubicado  en  el  directorio 
/usr /lib /python3 /site-packages/ 

Instalar  un  lanzamiento  oficial  con  Pip 

Una  forma  muy  sencilla  y automatica,  para  instalar  paquetes  en  Python,  es  usando 
un  instalador  independiente  llamado  pip.  Si  tienes  instalado  pip,  lo  unico  que 
necesitas,  es  utilizar  una  version  actualizada.  (Ya  que  en  algunos  casos  la  instalacion 
de  Django  no  trabaja,  con  versiones  muy  antiguas  de  pip),  pip  es  la  opcion 
recomendada  para  instalar  Django,  usando  virtualenv  y virtualenvwrapper. 

Pip  es  un  instalador  de  paquetes  Python,  usado  olicialmente  para  instalar 
paquetes  desde  Python  Package  Index  (PyPI).  Con  pip  puedes  instalar  Django  desde 
PyPI,  si  no  tienes  instalado  pip  instalalo  y luego  instala  Django. 
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■ Abre  una  terminal  de  comandos  y ejecuta  el  comando  easy_install  pip.  Este 
comando  instalara  pip  en  tu  sistema  (La  version  3.4  de  Python,  lo  incluye 
como  el  instalador  por  defecto). 

■ Opcionalmente  puedes  utilizar  virtualenv  o virtualenvwrapper.  Estas 
herramientas,  proveen  un  entorno  independiente  y aislado  para  ejecutar 
codigo  Python,  con  lo  cual  es  mas  practico  instalar  paquetes,  sin  alterar  el 
sistema,  ya  que  permite  instalar  paquetes,  sin  privilegios  de  administrador  y 
sin  riesgos  de  actualizar  dependencias  y con  la  ventaja  de  usar  el  interprete 
Python  que  desees.  Por  lo  que  de  ti  depende  que  quieras  aprender  a usarlo  o 
no. 

■ Si  estas  usando  Linux,  Mac  OS  X o algun  otro  sabor  de  Unix,  usa  el  siguiente 
comando  en  una  terminal  para  instalar  Django:  sudo  pip  install  django.  Si 
estas  usando  Windows,  inicia  el  shell  de  comandos  con  privilegios  de 
administrador  y ejecuta  el  comando:  pip  install  django.  Este  comando 
instalara  Django  en  el  directorio  de  paquetes  de  tu  instalacion  por  defecto  de 
Python. 

Si  estas  usando  virtualenv,  no  necesitas  usar  sudo  o privilegios  de  administrador, 
ya  que  los  paquetes  se  instalaran  en  un  directorio  independiente,  perteneciente  al 
entorno  de  paquetes  que  crea  el  mismo  virtualenv. 


Instalar  la  “Version  de  Desarrollo” 

Django  usa  Git  (http://git-scm.com)  para  el  control  del  codigo  fuente.  La  ultima 
version  de  desarrollo  esta  disponible  desde  el  repositorio  oficial  en  Git 
(https://github.com/django/django).  Si  quieres  trabajar  sobre  la  version  de 
desarrollo,  o si  quieres  contribuir  con  el  codigo  de  Django  en  si  mismo,  deberias 
instalar  Django  desde  el  repositorio  alojado  en  Git. 

Git  es  libre,  es  un  sistema  de  control  de  versiones  de  codigo  abierto,  usado  por  el 
equipo  de  Django  para  administrar  cambios  en  el  codigo  base.  Puedes  descargar  e 
instalar  manualmente  Git  de  http://git-scm.com/download,  sin  embargo  es  mas 
sencillo  instalarlo  con  el  manejador  de  paquetes  de  tu  sistema  operativo  (si  es  tu 
caso).  Puedes  utilizar  un  cliente  Git  para  hacerte  con  el  codigo  fuente  mas  actual  de 
Django  y,  en  cualquier  momento,  actualizar  tu  copia  local  del  codigo  fuente, 
conocido  como  un  checkout  local,  para  obtener  los  ultimos  cambios  y mejoras 
hechas  por  los  desarrolladores  de  Django. 

Cuando  uses  un  version  de  desarrollo,  debes  tener  en  mente  que  cualquier  cosa  se 
puede  romper  en  cualquier  momento,  por  lo  que  no  hay  garantias  de  nada  Una  vez 
dicho  esto,  tambien  debemos  decirte  que  algunos  miembros  del  equipo  de  Django 
ejecutan  sitios  de  production  sobre  la  version  de  desarrollo  con  el  incentivo  de 
mantenerlo  estable. 

Para  obtener  la  ultima  version  de  desarrollo,  sigue  los  siguientes  pasos: 

1.  Asegurate  de  tener  instalado  Git.  Puedes  obtener  el  software  de 
http://git-scm.com/,  tambien  puedes  encontrar  excelente  documentation  en 
http:  / / git-scm.com/documentation. 

2.  Clona  el  repositorio  usando  el  comando: 

git  clone  https://github.com/django/django  djmaster 
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3.  Localiza  el  directorio  site-packages  de  tu  instalacion  Python.  Usualmente  esta 
en  el  directorio:  /usr/lib/python3/site-packages.  Si  no  tienes  idea  de  su 
localization,  usa  la  linea  de  comandos  y tipea: 

python  -c  'import  sys,  pprint;  pprint.pprint(sys.path)' 

El  resultado  de  la  salida,  incluira  el  directorio  de  site-packages 

■ Si  no  tienes  un  directorio  site-packages,  crea  un  archivo  con  el  nombre: 
djmaster.pth  editalo  y agrega  la  ruta  completa  al  directorio  djmaster.  Por 
ejemplo,  tu  archivo  puede  contener  una  linea  como  la  siguiente: 

o /path /to /djmaster 

■ La  carpeta:  djmaster/django/bin  en  la  ruta  de  tu  sistema.  Es  el  directorio 
que  incluye  las  utilidades  administrativas,  tales  como  django-admin.py. 

Si  los  archivo  .pth  son  nuevos  para  ti,  puedes  aprender  mas  de  ellos  en 
® http://www.djangoproject.eom/r/python/site-module/. 

Luego  de  descargar  el  codigo  fuentes  desde  Git  y haber  seguido  los  pasos 
anteriores,  no  necesitas  ejecutar  setup.py  install  jAcabas  de  hacer  este  trabajo  a 
mano! 

Debido  a que  el  codigo  de  Django  cambia  a menudo  corrigiendo  bugs  y agregando 
funcionalidades,  probablemente  quieras  actualizarlo  con  frecuencia  o alguna  que 
otra  vez.  Para  actualizar  el  codigo,  solo  ejecuta  el  comando:  git  pull  origin  master 
desde  el  directorio  djmaster. 

Cuando  ejecutes  este  comando,  Git  contactara  https://github.com/django/django 
y automaticamente  determinara  si  el  codigo  ha  cambiado  y actualizara  tu  version 
local  del  codigo  con  cualquier  cambio  que  se  haya  hecho  desde  la  ultima 
actualization.  Es  muybueno. 

Finalmente,  si  estas  usando  la  version  de  desarrollo,  necesitas  conocer  la  version 
de  Django  que  estas  ejecutando.  Conocer  el  numero  de  version  es  importante  en  caso 
de  que  alguna  vez  necesites  ayuda  de  la  comunidad  o para  enviar  alguna  mejora  del 
framework.  En  estos  casos,  es  necesario  informar  sobre  la  revision,  esta  revision  es 
tambien  conocida  como  “commit”.  Para  encontrar  el  commit  actual,  tipea  “git  log  -1” 
dentro  del  directorio  django  y busca  el  identificador  despues  del  “commit”.  Este 
numero  cambia  cada  vez  que  Django  cambia,  se  corrige  algun  error,  se  agrega  alguna 
caracteristica,  se  mejora  la  documentation  o se  implementa  cualquier  otra  cosa. 


Probando  la  instalacion 

Para  obtener  un  poco  mas  de  retroalimentacion,  despues  del  proceso  de  instalacion, 
tomemonos  un  momento  para  probar  la  instalacion.  Usando  la  linea  de  comandos, 
cambiate  a otro  directorio  (no  al  directorio  que  contiene  el  directorio  django)  e inicia 
el  interprete  interactivo  tipeando  python3  o python  dependiendo  de  la  version  que 
estes  usando.  Si  el  proceso  de  instalacion  fue  exitoso,  deberias  poder  importar  el 
modulo  django: 

>»  import  django 
>»  django  .VERSION 
(1,8,  'final',  0) 
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Ejemplos  en  el  interprete  interactive 

El  interprete  interactive  de  Python  es  un  programa  de  linea  de  comandos  que 
te  permite  escribir  un  programa  Python  de  forma  interactiva.  Para  iniciarlo 
solo  ejecuta  el  comando  python  o python3  en  la  linea  de  comandos 

Durante  todo  este  libro,  mostraremos  ejemplos  de  codigo  Python  como  si 
estuviesen  escritos  en  el  interprete  interactivo.  El  triple  signo  de  mayor  que 
(»>)  es  el  prompt  de  Python.  Si  estas  siguiendo  los  ejemplos 
interactivamente,  no  copies  estos  signos. 

Toma  en  cuenta  que  en  el  interprete  interactivo,  las  declaraciones 
multilinea  son  completadas  con  tres  puntos  (...). 

Por  ejemplo: 

»>from  future import  print_function 

»>  print  ( Esta  es  una 

...  cadena  de  texto  que  abarca 

...  tres  lineas. ) 

Esta  es  una 

cadena  de  texto  que  abarca 
tres  lineas. 

»>  def  mi_funcion(valor): 
print  (valor) 

»>  mi_funcion('hola') 
hola 

Estos  tres  puntos  adicionales,  al  inicio  de  la  linea  son  insertados  por  el 
interprete  Python  - No  son  parte  de  la  entrada  de  datos.  Los  hemos  incluido 
aqui  para  ser  fieles  a la  salida  del  interprete.  Si  copias  estos  ejemplos, 
asegurate  de  no  incluir  estos  tres  puntos. 

Observa  tambien  como  importamos  la  funcion  print_function  del  paquete 
future,  para  compatibilidad  con  Python  3.  Esta  es  una  solution  perfecta  para 
proyectos  en  los  cuales  se  requiere  mantener  una  compatibilidad  entre 
distintas  versiones  de  Python,  sin  tener  que  ramificar  el  codigo  entre  versiones 
2.x  y 3.x  en  especifico,  de  esta  forma  es  posible  mantener  el  codigo 
independiente  de  la  version  de  Python. 


Configurer  la  base  de  datos 


En  este  punto,  podrias  escribir  una  aplicacion  Web  usando  Django,  por  que  el  unico 
prerrequisito  de  Django  es  una  instalacion  funcionando  de  Python.  Sin  embargo,  este 
libro  se  centra  en  una  de  las  mejores  funcionalidades  de  Django,  el  desarrollo  de 
sitios  Web  con  soporte  para  base  de  datos , para  ello  necesitaras  instalar  un  servidor 
de  base  de  datos  de  algun  tipo,  para  almacenar  tus  datos. 

Si  solo  quieres  comenzar  a jugar  con  Django,  salta  a la  section  titulada  “Empezar 
un  proyecto”  - pero  creenos,  querras  instalar  una  base  de  datos  finalmente.  Todos 
los  ejemplos  de  este  libro  asumen  que  tienes  una  base  de  datos  configurada. 

Elasta  el  momento  de  escribir  esto,  Django  admite  oficialmente  estos  cuatro 
motores  de  base  de  datos: 
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PostgreSQL 

http://www.postgresql.org/ 

SQLite  3 

http://www.sqlite.org/ 

MySQL 

http://www.mysql.com/ 

Oracle 

http://www.oracle.com/ 

Ademas  de  las  bases  de  datos  oficialmente  soportadas,  existen  otras  ofrecidas  por 
terceros,  que  permiten  utilizar  otras  bases  de  datos  con  Django  como  son:  SAP  SQL, 
Anywhere,  IBM,  DB2,  Microsoft  SQL  Server,  Firebird,  ODBC,  ADSDB. 

En  general,  todos  los  motores  que  listamos  aqui  trabajan  bien  con  Django  (Una 
notable  exception,  es  el  soporte  opcional  para  GIS,  el  cual  es  mas  poderoso  usando 
PostgreSQL,  que  usando  otras  bases  de  datos.)  Si  no  estas  atado  a ningun  sistema  y 
tienes  la  libertad  para  cambiarte  a cualquier  base  de  datos,  nosotros  recomendamos 
PostgreSQL,  el  cual  logra  un  balance  fino  entre  el  costo,  caracteristicas,  velocidad  y 
estabilidad. 

Configurar  la  base  de  datos,  es  un  proceso  que  toma  dos  pasos: 

■ Primero,  necesitas  instalar  y configurar  la  base  de  datos  en  si  mismo.  Este 
proceso  va  mas  alia  de  los  alcances  de  este  libro,  pero  cada  una  de  las  cuatro 
bases  de  datos  que  mencionamos  anteriormente  posee  una  vasta 
documentation  en  su  sitio  Web  (Si  usas  un  servicio  de  hosting  compartido,  lo 
mas  probable  es  que  la  base  de  datos  ya  este  configurada  y lista  para  usarse.) 

■ Segundo,  necesitas  instalar  ciertas  librerfas  Python  para  la  base  de  datos  en 
especifico  que  vayas  a utilizar  (drivers).  Estas  forman  parte  del  codigo  de 
terceros,  que  permiten  a Python  conectarse  a la  base  de  datos.  Repasararemos 
mas  los  requisitos  en  las  siguientes  secciones. 

SQLite  merece  especial  atencion  como  herramienta  de  desarrollo.  Es  un  motor  de 
base  de  datos  extremadamente  simple  y no  requiere  ningun  tipo  de  instalacion  y 
configuration  del  servidor.  Es  por  lejos  el  mas  facil  de  configurar  si  solo  quieres  jugar 
con  Django,  y viene  incluido  en  la  biblioteca  estandar  de  Python. 

En  Windows,  obtener  los  drivers  binarios  para  cualquier  base  de  datos  es  a veces 
un  proceso  complicado.  Ya  que  solo  estas  iniciandote  con  Django,  recomendamos 
usar  Python  3 y el  soporte  incluido  para  SQLite. 

La  compilation  de  drivers  puede  ser  estresante. 

Usar  Django  con  PostgreSQL 

Si  estas  utilizando  PostgreSQL,  necesitaras  el  paquete  psycopg2  disponible  en 
® http://www.djangoproject.eom/r/python-pgsql/.  Toma  nota  de  la  version  de 
Python  que  estas  usando;  necesitaras  esta  information  para  descargar  la  version 
apropiada. 

Si  estas  usando  PostgresSQL  en  Windows,  puedes  encontrar  los  binarios 
precompilados  de  psycopg  en  http://www.djangoproject.com/r/python- 
pgsql/windows/. 

Si  estas  usando  Linux,  checa  el  instalador  o gestor  de  paquetes  que  ofrece  tu 
sistema,  busca  algo  llamado  “python-psycopg”,  “psycopg-python”,  “python- 
postgresql”  o algo  similar. 
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Usar  Django  con  SQLite  3 

Si  quieres  usar  SQLite,  estas  de  suerte,  ya  que  no  necesitas  instalar  nada,  porque 
Python  ofrece  soporte  nativo  para  SQLite,  ademas  Django  ofrece  por  omision  usar 
esta  configuracion,  por  lo  que  puedes  saltarte  esta  section. 


Usar  Django  con  MySQL 

Django  requiere  MySQL  4.0  o superior;  la  version  3.x  no  admite  subconsultas 
anidadas,  ni  algunas  otras  sentencias  SQL  perfectamente  estandar. 

Tambien  necesitas  instalar  el  paquete  MySQLdb  disponible  en: 

(§)  http://www.djangoproject.eom/r/python-mysql/. 

Si  estas  usando  Linux,  checa  el  instalador  o gestor  de  paquetes  que  ofrece  tu 
sistema  y busca  algo  llamado  “python-mysql”,  “python-mysqldb”,  “mysql-python”  o 
algo  similar. 


Django  con  Oracle 

Django  trabaja  con  versiones  servidor  de  Oracle  9i  o mas  alto. 

Si  estas  usando  Oracle  necesitas  instalar  la  libreria  cx_Oracle,  disponible  en 
(f)  http://cx-oracle.sourceforge.net/.  Usa  una  version  superior  a la  4.31,  pero  evita  la 
version  5.0  ya  que  existe  un  error  en  la  version  del  controlador.  La  version  5.0.1 
corrige  ese  error,  de  cualquier  forma  usa  en  lo  posible  una  version  superior. 


Usar  Django  sin  una  base  de  datos 

Como  mencionamos  anteriormente,  Django  actualmente  no  requiere  una  base  de 
datos.  Si  solo  quieres  usar  este  como  un  servidor  dinamico  de  paginas  que  no  use  una 
base  de  datos,  esta  perfectamente  bien. 

Con  esto  dicho,  ten  en  cuenta  que  algunas  de  las  herramientas  extras  de  Django 
requieren  una  base  de  datos,  por  lo  tanto  si  eliges  no  usar  una  base  de  datos,  perderas 
estas  utilidades.  (Senalaremos  estas  utilidades  a lo  largo  del  libro). 

Comenzar  un  proyecto 

Una  vez  que  has  instalado  Python,  Django  y (opcionalmente)  una  base  de  datos 
(incluyendo  los  controladores),  puedes  empezar  a dar  tus  primeros  pasos  en  el 
desarrollo  de  aplicaciones,  creando  un  proyecto. 

Un  proyecto  es  una  coleccion  de  configuraciones  para  una  instancia  de  Django, 
incluyendo  configuracion  de  base  de  datos,  opciones  especificas  de  Django  y 
configuraciones  especificas  de  aplicaciones. 

Si  esta  es  la  primera  vez  que  usas  Django,  tendras  que  tener  cuidado  de  algunas 
configuraciones  iniciales. 

Primero  crea  un  nuevo  directorio  para  empezar  a trabajar,  por  ejemplo  algo  como 
/home/username/djeode/. 
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^Donde  deberia  estar  este  directorio? 

Si  has  trabajado  con  PHP,  probablemente  pondrias  el  codigo  debajo  de  la  carpeta  raiz 
del  servidor  Web  (en  lugares  como  /var/www).  Con  Django,  no  tienes  que  hacer  esto. 
No  es  una  buena  idea  poner  cualquier  codigo  Python  en  la  carpeta  raiz  del  servidor 
Web,  porque  al  hacerlo  se  arriesga  a que  la  gente  sea  capaz  de  ver  el  codigo  en  la  Web. 
Esto  no  es  bueno  para  la  seguridad. 

Pon  tu  codigo  en  algun  directorio  fuera  de  la  carpeta  raiz,  cambiate  al  directorio 
que  acabas  de  crear  y ejecuta  el  siguiente  comando: 

django-admin.py  startproject  misitio 

Este  comando  creara  un  directorio  llamado  misitio  en  el  directorio  actual. 


Nota:  django-admin.py  deberia  estar  en  la  ruta  de  busqueda  de  tu  sistema 
o PATE1,  si  instalaste  Django  con  la  utilidad  setup.py. 

Si  estas  usando  la  version  de  desarrollo,  puedes  encontrar  django- 
admin.py  en  djmaster/django/bin.  Como  vas  a utilizar  con  frecuencia  django- 
admin.py  considera  agregarlo  a tu  PATEL  En  Unix,  puedes  hacer  un  enlace 
simbolico  a /usr/local/bin  usando  un  comando  como  sudo  In  -s 
/path/to/django/ bin /django-admin.py  /usr/local/bin/django-admin.py.  En 
Windows,  puedes  actualizar  tu  variable  de  entorno  PATE!  de  forma  grafica. 

Si  instalaste  Django  a traves  del  gestor  de  paquetes  de  tu  distribution, 
django-admin.py  o en  sistemas  Windows,  ahora  tienes  un  ejecutable  llamado 
django-admin,  A si  que  solo  debes  ejecutar  el  comando  (omitiendo  el  .py): 

django-admin.py  startproject  misitio 

Si  obtienes  un  mensaje  como  “permiso  denegado”,  al  usar  el  comando 
django-admin.py  startproject,  necesitas  cambiarle  los  permisos  al  archivo, 
para  hacerlo,  navega  al  directorio  donde  se  instalo  django-admin.py,  (e.g.,  cd 
/usr/local/bin)  y ejecuta  el  comando  chmod  +x  django-admin.py. 


El  comando  startproject  crea  un  directorio  de  trabajo  que  contiene  varios 
archivos: 

misitio/ 

manage . py 
misitio/ 

init . py 

settings . py 
urls . py 
wsgi. py 

Estos  archivos  son  los  siguientes: 

■ misitio/:  El  directorio  de  trabajo  externo  misitio/,  es  solo  un  contenedor,  es 
decir  una  carpeta  que  contiene  nuestro  proyecto.  Por  lo  que  se  le  puede 
cambiar  el  nombre  en  cualquier  momento  sin  afectar  el  proyecto  en  si. 

■ manage. py:  Una  utilidad  de  linea  de  comandos  que  te  permite  interactuar 
con  un  proyecto  Django  de  varias  formas.  Usa  manage.py  help  para  ver  lo  que 
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puede  hacer.  No  deberias  editar  este  archivo,  ya  que  este  es  creado  en  el 
directorio  convenientemente  para  manejar  el  proyecto. 

■ misitio/misitio/:  El  directorio  interno  misitio/  contiene  el  paquete  Python 
para  tu  proyecto.  El  nombre  de  este  paquete  Python  se  usara  para  importar 
cualquier  cosa  dentro  del.  (Por  ejemplo  import  misitio. settings). 

■ init .py:  Un  archivo  requerido  para  que  Python  trate  el  directorio  misitio 

como  un  paquete  o como  un  grupo  de  modulos.  Es  un  archivo  vacio  y 
generalmente  no  necesitaras  agregarle  nada. 

■ settings. py:  Las  opciones/configuraciones  para  nuestro  proyecto  Django. 
Dale  un  vistazo,  para  que  te  des  una  idea  de  los  tipos  de  configuraciones 
disponibles  y sus  valores  predeflnidos. 

■ urls.py:  Declaration  de  las  URLs  para  este  proyecto  de  Django.  Piensa  que  es 
como  una  “tabla  de  contenidos”  de  tu  sitio  hecho  con  Django. 

■ wsgi.py:  El  punto  de  entrada  WSGI  para  el  servidor  Web,  encargado  de  servir 
nuestro  proyecto.  Para  mas  detalles  consulta  el  c apitulol2. 

Todos  estos  pequenos  archivos,  constituyen  un  proyecto  Django,  que  puede 
albergar  multiples  aplicaciones. 

Si  estas  usando  SQLite  como  base  de  datos,  no  necesitaras  crear  nada  de 
antemano  - la  base  de  datos  se  creara  automaticamente  cuando  esta  se  necesite. 

Observa  que  la  variable  INSTALLED_APPS,  hacia  el  final  del  archivo  settings.py, 
contiene  el  nombre  de  todas  las  aplicaciones  Django  que  estan  activadas  en  esta 
instancia  de  Django.  Las  aplicaciones  pueden  ser  empacadas  y distribuidas  para  ser 
usadas  por  otros  proyectos. 

De  forma  predeterminada  INSTALLED_AP/’5  contiene  todas  las  aplicaciones,  que 
vienen  por  defecto  con  Django: 

■ django.contrib. admin  - La  interfaz  administrativa. 

■ django.contrib. auth  - El  sistema  de  autentificacion. 

■ django.contrib. contenttypes  - Un  framework  para  tipos  de  contenidos. 

■ django.contrib. sessions  - Un  framework,  para  manejar  sesiones 

■ django.contrib. messages  - Un  framework  para  manejar  mensajes 

■ django.contrib. staticfiles  - Un  framework  para  manejar  archivos  estaticos. 

Estas  aplicaciones  se  incluyen  por  defecto,  como  conveniencia  para  los  casos  mas 
comunes. 

Algunas  de  estas  aplicaciones  hacen  uso,  de  por  lo  menos  una  tabla  de  la  base  de 
datos,  por  lo  que  necesitas  crear  las  tablas  en  la  base  de  datos,  antes  de  que  puedas 
utilizarlas,  para  hacerlo  entra  al  directorio  que  contiene  tu  proyecto  (cd  misitio)  y 
ejecuta  el  comando  siguiente,  para  activar  el  proyecto  Django.: 


python  manage. py  migrate 
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El  comando  migrate  busca  la  variable  INSTALLED_APPS  y crea  las  tablas 
necesarias  de  cada  una  de  las  aplicaciones  registradas  en  el  archivo  settings.py,  que 
contiene  todas  las  aplicaciones.  Veras  un  mensaje  por  cada  migration  aplicada. 

El  servidor  de  desarrollo 

Para  obtener  un  poco  de  information  y mas  retroalimentacion,  ejecuta  el  servidor  de 
desarrollo  de  Django,  para  ver  el  proyecto  en  action. 

Django  incluye  un  servidor  Web  ligero  (Que  es  llamado  con  el  comando 
“runserver”)  que  puedes  usar  mientras  estas  desarrollando  tu  sitio.  Incluimos  este 
servidor  para  que  puedas  desarrollar  tu  sitio  rapidamente,  sin  tener  que  lidiar  con 
configuraciones  de  servidores  Web  para  production  (por  ejemplo,  Apache)  hasta  que 
estes  listo  para  production. 

Este  servidor  de  desarrollo  vigila  tu  codigo  a la  espera  de  cambios  y se  reinicia 
automaticamente,  ayudandote  a hacer  algunos  cambios  rapidos  en  tu  proyecto  sin 
necesidad  de  reiniciar  nada. 

Para  iniciar  el  servidor,  entra  en  el  directorio  que  contiene  tu  proyecto  (cd  misitio) 
si  aun  no  lo  has  hecho  y ejecuta  el  comando: 

python  manage. py  runserver 

Veras  algo  parecido  a esto: 

Performing  system  checks... 

System  check  identified  no  issues  (0  silenced). 

February  16,  2014  - 21:17:11 

Django  version  1.8,  using  settings  ' misitio . settings ' 

Starting  development  server  at  http : //127 . 0 . 0 . 1 : 8000/ 

Quit  the  server  with  CONTROL-C. 

El  comando  runserver  inicia  el  servidor  de  desarrollo  en  el  puerto  8000, 
escuchando  solo  conexiones  locales.  Ahora  que  el  servidor  esta  corriendo,  visita  la 
direction  http:// 127.0.0. 1:8000/  con  tu  navegador  Web.  Veras  una  pagina  de 
“Bienvenido  a Django”  sombreada  con  un  azul  pastel  agradable.  jFunciona! 
“Bienvenido  a Django” 

^ Iocalhost8000  ^ C 1 1 P & {§  ft  S 


jFunciona! 

Felicidades,  haz  creado  tu  primera  pagina  usando  Django. 


Por  supuesto  que  actualmente  no  hace  nada,  ya  que  necesitas  primero  crear  una  una  aplicacion  ejecutando  python  manage. py  startapp  [nombre 

aplicacion] . 

Estas  viendo  este  mensaje,  porque  el  archivo  de  configuraciones  de  Django,  esta  fijado  en  debog  = True  y todavia  no  haz  configurado  ninguna  URL's. 
jManos  a la  obra! 


Imagen  2.1  jPagina  de  bienvenida  a django,  jFunciona! 

Aunque  el  servidor  de  desarrollo  es  extremadamente  util  para,  bueno;  desarrollar, 
resiste  la  tentacion  de  usar  este  servidor  en  cualquier  entorno  parecido  a production. 
El  servidor  de  desarrollo  puede  manejar  fiablemente  una  sola  petition  a la  vez,  y no 
ha  pasado  por  una  auditoria  de  seguridad  de  n in  gun  tipo.  Cuando  sea  el  momento  de 
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lanzar  tu  sitio,  mira  el  Capitulo  12  para  obtener  mas  information,  sobre  como  hacerlo 
con  Django. 

Cambiar  el  host  y el  puerto 

Por  defecto,  el  comando  runserver  inicia  el  servidor  de  desarrollo  en  el  puerto  8000, 
escuchando  solo  conexiones  locales.  Si  quieres  cambiar  el  puerto  del  servidor, 
pasaselo  a este  como  un  argumento  en  la  linea  de  comandos: 

python  manage. py  runserver  8080 

Tambien  puedes  cambiar  las  direcciones  IP  que  escucha  el  servidor.  Esto  es  utilizado 
especialmente  si  quieres  compartir  el  desarrollo  de  un  sitio  con  otros  desarrolladores 
o miembros  de  tu  equipo.  Por  ejemplo  la  direction  IP  192.148.1.103  hara  que  Django 
escuche  sobre  cualquier  interfaz  de  red,  permitiendo  que  los  demas  miembros  del 
equipo  puedan  conectarse  al  servidor  de  desarrollo. 

python  manage. py  runserver  192.148.1.103:8000 

Cuando  hagas  esto,  otras  computadoras  de  tu  red  local,  podran  conectarse  a tu  sitio, 
visitando  la  direction  IP  directamente  en  sus  navegadores  por  ejemplo  usando: 
http://192.148. 1.103:8000/  . (Ten  en  cuenta  que  para  poder  acceder  a tu  red,  es 
necesario  primero  determinar  la  direction  IP  de  tu  red  local,  en  sistemas  Unix, 
puedes  usar  el  comando  “ifconfig”  en  la  linea  de  comandos  o terminal,  en  sistemas 
Windows  puedes  conseguir  esta  misma  information  usando  el  comando  “ipconfig”  ) 


<?,Que  sigue? 

Ahora  que  tienes  todo  instalado  y el  servidor  de  desarrollo  funcionando,  en  el 
proximo  capitulo  Los  principios  de  las  paginas  Web  dinamicas  escribiras  algo  de 
codigo,  que  muestra  como  servir  paginas  Web  usando  Django. 


CAPITULO  3 


Los  principios  basicos  de  las 
paginas  Web  dinamicas 

En  el  capitulo  anterior,  explicamos  como  crear  un  proyecto  en  Django  y como 
poner  en  marcha  el  servidor  de  desarrollo.  Por  supuesto,  el  sitio  no  hace  nada  util 
todavia  - solo  muestra  el  mensaje  “It  worked!”.  Cambiemos  eso.  Este  capitulo 
presenta  como  crear  paginas  web  dinamicas  con  Django. 

Tu  primera  pagina  creada  con  Django 

Como  primer  objetivo,  vamos  a crear  una  pagina  web,  que  muestre  por  salida  el 
famoso  y clasico  mensaje:  “Hola  mundo”. 

Si  quisieramos  publicar  un  simple  “Hola  mundo”  en  una  pagina  web,  sin  usar  un 
framework,  simplemente  escribiriamos  “Hola  mundo”  en  un  archivo  de  texto  y lo 
llamariamos  "Hola_mundo",  despues  lo  subiriamos  a alguna  parte  de  nuestro 
servidor  Web.  Fijate  en  el  proceso,  hemos  especificado  dos  piezas  de  information 
acerca  de  la  pagina  web:  tenemos  el  contenido  que  es  la  cadena  "Hola  mundo"  y la 
URL  que  puede  ser  http://www.example.com/hola.html  o tal  vez 
http://www.example.com/archivos/hola.html  si  lo  pusimos  en  un  subdirectorio. 

Con  Django,  es  necesario  especificar  esas  mismas  cosas,  pero  de  diferente  modo. 
El  contenido  de  la  pagina  sera  producido  por  la  funcion  vistay  la  URL  se  especificara 
en  la  URLconf. 

Primero  escribamos  la  vista  “Hola  mundo”,  podriamos  crear  una  aplicacion 
Django  para  este  proposito,  pero  lo  haremos  de  forma  manual,  para  conocer  paso  a 
paso  el  proceso  de  creation,  mas  adelante  te  mostraremos  como  crear  aplicaciones 
de  forma  automatica. 

Tu  primera  vista  creada  con  Django 

Dentro  del  directorio  misitio,  el  cual  creamos  en  el  capitulo  anterior  con  el  comando 
django-admin.py  startproject,  crea  un  archivo  vacio  llamado  views. py  en  el  mismo 
nivel  que  settings.py.  Este  modulo  Python  contendra  la  vista  que  usaremos  en  este 
capitulo.  Observa  que  no  hay  nada  especial  acerca  del  nombre  views.py  - A Django 
no  le  interesa  como  lo  llames.  Le  dimos  este  nombre  solo  por  convention  y para 
benelicio  de  otros  desarrolladores  que  lean  nuestro  codigo. 

Nuestra  vista  “Hola  mundo”  sera  bastante  simple.  Esta  es  la  funcion  completa,  la 
cual  incluye  las  declaraciones  que  debemos  escribir  en  un  archivo  llamado  views.py: 


views . py 


from  django.http  import  HttpResponse 
def  hola(request): 

return  HttpResponse("Hola  Mundo') 
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Repasemos  el  codigo  anterior  linea  a linea: 

■ Primero,  importamos  la  clase  HttpResponse,  la  cual  pertenece  al  modulo 
django.http.  Necesitamos  importar  esta  clase  porque  sera  usada 
posteriormente  en  nuestro  codigo. 

■ Despues,  definimos  una  funcion  llamada  hola,  la  funcion  vista. 

■ Cada  funcion  de  vista  o vista,  toma  al  menos  un  parametro  llamado  por 
convention  request.  El  cual  es  un  objeto  que  contiene  information  sobre  la 
vista  que  llama  a la  pagina  actual,  la  cual  es  una  instancia  de  la  clase 
django.http.HttpRequest.  En  este  ejemplo,  no  hace  nada  el  metodo  request, 
no  obstante  siempre  debe  ser  el  primer  parametro  de  cualquier  vista. 

■ Observa  tambien  que  el  nombre  de  la  funcion  no  importa;  ya  que  no  tiene  que 
ser  nombrada  de  una  determinada  forma  para  que  Django  la  reconozca.  La 
llamamos  hola,  porque  claramente  indica  lo  que  hace  esta  funcion,  pero  se 
podria  haber  llamado,  hola_maravilloso_y_bello_mundo,  o algo  igualmente 
provocador.  En  la  siguiente  section  “Tu  primera  URLconf”,  te  mostraremos 
como  le  decimos  a Django,  que  encuentre  esta  funcion. 

La  funcion  que  hemos  creado,  es  una  simple  linea:  que  retorna  un  objeto 
HttpResponse  que  ha  sido  instanciado  con  el  texto  "Hola  mundo",  pero  por  ejemplo 
si  quisieramos  mostrar  por  salida  HTML  directamente,  lo  podriamos  hacer  asi, 
remplaza  la  vista  anterior  con  esta: 


views . py 


from  django.http  import  HttpResponse 

HTML  = 

<!DOCTYPE  html> 

<html  lang="es"> 

<head> 

<meta  http-equiv="content-type"  content-'text/html;  charset=utf-8"> 
<meta  name="robots"  content="NONE,NOARCHIVE"> 

<title>Hola  mundo</title> 

<style  type- 'text/css"> 

html  * { padding:0;  margin:0; } 

body  * { padding:10px  20px; } 

body  * * { padding:0; } 

body  { font:small  sans-serif; } 

body>div  { border-bottorrrlpx  solid  #ddd; } 

hi  { font-weight:normal; } 

#summary  { background:  #eOebff; } 

</style> 

</head> 

<body> 

<div  id="summary"> 

<hl>jHola  Mundo!</hl> 

</div> 

</bodyx/html> 

def  hola(request): 

return  HttpResponse(HTML) 
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La  lection  principal  que  debes  aprender  aqui,  es  que  una  vista  es  solo  una  funcion 
Python,  que  toma  como  primer  argumento  una  petition  HttpRequest  y retorna  como 
respuesta  una  instancia  de  HttpResponse.  Por  lo  que  una  funcion  en  Python  es  una 
vista  en  Django.  (Hay  excepciones,  pero  las  veremos  mas  adelante) 


Tu  primera  URLconf  creada  con  Django 

En  este  punto,  puedes  ejecutar  otra  vez  python  manage. py  runserver  y veras  de  nuevo 
el  mensaje  “Bienvenido  a Django”,  sin  rastros  de  la  vista  “Hola  mundo”  que  creamos 
anteriormente.  Esto  se  debe  a que  nuestro  proyecto  misitio,  no  sabe  nada  acerca  de 
esta  vista,  por  lo  que  necesitamos  decide  a Django  explicitamente,  como  activar  esta 
vista  para  una  determinada  URL  (Continuando  con  la  analogia  que  mencionamos 
anteriormente,  sobre  publicar  archivos  estaticos,  esto  seria  como  crear  un  archivo 
HTML,  sin  subirlo  al  directorio  del  servidor).  Para  enganchar,  enlazar  o apuntar  a 
una  determinada  URL  una  funcion  vista,  usamos  una  URLconf. 

Una  URLconf  es  como  una  tabla  de  contenidos  para  tu  sitio  web  hecho  con 
Django.  Basicamente,  es  un  mapeo  entre  los  patrones  URL  y las  funciones  de  vista 
que  deben  ser  llamadas  por  esos  patrones  URL.  Es  como  decide  a Django,  “Para  esta 
URL,  llama  a este  codigo,  y para  esta  otra  URL,  llama  a este  otro  codigo”.  Por  ejemplo, 
“Cuando  alguien  visita  la  URL  /hola/,  llama  a la  funcion  vista_hola()  la  cual  esta  en  el 
modulo  Python  views.py.” 

Cuando  ejecutaste  django-admin.py  startproject  en  el  capitulo  anterior,  el  script 
creo  automaticamente  una  URLconf  por  ti:  el  archivo  urls.py.  Por  omision,  se  vera 
asi: 


from  django.conf.urls  import  include,  url 
from  django.contrib  import  admin 

urlpatterns  = [ 

# Ejemplos: 

# url(r'A$',  'misitio. views. home',  name-home'), 

# url(r'Ablog/',  include('blog.urls')), 

url(r'Aadmin/',  include(admin.site.urls)), 

] 

Repasemos  el  codigo  anterior  linea  a linea: 

■ La  primera  linea  importa  las  funciones:  url  e include,  del  modulo 
django.conf.urls,  la  funcion  url  es  una  tupla,  donde  el  primer  elemento  es  una 
expresion  regular  simple  y el  segundo  elemento  es  la  funcion  de  vista  que  se 
usa  para  ese  patron,  mientras  que  la  funcion  include  se  encarga  de  importar 
modulos  que  contienen  otras  URLconf,  al  camino  de  busqueda  de  Python, 
como  una  forma  de  “incluir”  urls  que  pertenecen  a otro  paquete,  en  este  caso 
al  sitio  administrative,  que  viene  activado  por  defecto  (Esto  lo  veremos  mas 
adelante). 

■ Despues  tenemos  a la  funcion  urlpatterns (),  una  variable  que  recibe  los 
argumentos  de  las  url  en  forma  de  lista,  inclusive  cadenas  de  caracteres 
vacias. 

■ Por  defecto,  todo  lo  que  esta  en  la  URLconf  esta  comentado  e incluye  algunos 
ejemplos  de  configuraciones  comunmente  usados,  a exception  del  sitio 
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administrative,  el  cual  esta  activado  por  omision.  (Para  desactivarlo,  solo  es 
necesario  comentarlo.) 

■ Si  ignoramos  el  codigo  comentado  y las  referencias  a la  interfaz 
administrativa,  esto  es  esencialmente  una  URLconf: 

from  django.conf.urls  import  url 

urlpatterns  = [ 

] 

El  principal  punto  que  debes  notar  aqui  es  la  variable  urlpatterns,  la  cual  Django 
espera  encontrar  en  tu  modulo  ROOT_URLCONF.  Esta  variable  define  el  mapeo  entre 
las  URLs  y el  codigo  que  manejan  esas  URLs.  Por  defecto,  todo  lo  que  esta  en  la 
URLconf  esta  comentado  - tu  aplicacion  de  Django  es  una  pizarra  blanca.  (Como 
nota  adicional,  esta  es  la  forma  en  la  que  Django  sabia  que  debia  mostrar  la  pagina  “It 
worked!”  en  el  capitulo  anterior.  Si  la  URLconf  esta  vacia,  Django  asume  que  acabas 
de  crear  el  proyecto,  por  lo  tanto,  muestra  ese  mensaje). 

Para  agregar  una  URL  y una  vista  a la  URLconf,  solamente  agrega  un  mapeo,  es 
decir  un  enlace  entre  el  patron  URL  y la  funcion  vista  a usar.  Esta  es  la  forma  en  la 
que  enganchamos  la  vista  hola  a la  URL: 


urls .py 


from  django.conf.urls  import  url 
from  misitio. views  import  hola 

urlpatterns  = [ 

url(r'Ahola/$',  hola), 

] 


(Nota  que  borramos  todo  el  codigo  que  hace  referencia  a la  interfaz  administrativa,  y 
dejamos  la  URLconf  vacia,  para  mostrar  como  funcionan  las  vistas  en  Django, 
activaremos  la  interfaz  administrativa  en  capitulos  posteriores.) 

Observa  que  hicimos  dos  cambios: 

■ Primero,  importamos  la  vista  hola,  desde  el  modulo  misitio /views.py  que  en  la 
sintaxis  de  import  de  Python  se  traduce  a misitio.views.  (La  cual  asume  que  el 
paquete  misitio/views.py,  esta  en  la  ruta  de  busqueda  de  Python  o python 
path). 

■ Luego,  agregamos  la  linea  url(r'Ahola/$',  hola),  a urlpatterns  Esta  linea  hace 
referencia  a un  URLpattern  - Una  tup  la  de  Python  en  donde  el  primer 
elemento  es  una  expresion  regular  simple  y el  segundo  elemento  es  la  funcion 
de  vista  que  usa  para  manejar  ese  patron.  La  url()  puede  tomar  argumentos 
opcionales,  los  cuales  cubriremos  mas  a fondo  en  el  Capitulo8, 

Un  detalle  importante  que  hemos  introducido  aqui,  es  el  caracter  r al  comienzo  de 
la  expresion  regular.  Esto  le  dice  a Python  que  es  una  “cadena  en  crudo”  - lo  que 
permite  que  las  expresiones  regulares  sean  escritas  sin  demasiadas  sentencias  de 
escape  tal  como  cadenas  ’\n'  , la  cual  es  una  cadena  que  indica  una  nueva  linea. 
Cuando  agregamos  la  r hicimos  una  cadena  en  crudo,  la  cual  Python  no  tratar  de 
escapar  con  r'\n'  una  cadena  de  dos  caracteres,  la  diagonal  y la  “n”  minuscula.  Para 
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evitar  colisiones  entre  las  diagonales  que  usa  Python  y las  encontradas  en  las 
expresiones  regulares,  es  fuertemente  recomendado  usar  cadenas  en  crudo,  cada  vez 
que  necesites  definir  una  expresion  regular  en  Python.  Todos  los  patrones  en  este 
libro  usan  cadenas  en  crudo. 

En  resumidas  cuentas,  le  estamos  diciendo  a Django  que  cualquier  petition  a la 
URL  /hola/  sea  manejada  por  la  funcion  de  vista:  /hola/  (y  no,  no  tienen  que  llamarse 
igual) 


□ Tu  ruta  de  python  o python  path 


Python  path  es  la  lista  de  directories  en  tu  sistema  en  donde  Python  buscara  cuando 
uses  la  sentencia  import  de  Python. 

Por  ejemplo,  supongamos  que  tu  Python  path  tiene  el  valor  [", 
7usr/lib/python3.4/site-packages',  '/home/username/djeode/'].  Si  ejecutas  el 
codigo  Python  from  foo  import  bar,  Python  en  primer  lugar  va  a buscar  el  modulo 
11am ado  foo.py  en  el  directorio  actual.  (La  primera  entrada  en  el  Python  path,  una 
cadena  de  caracteres  vacia,  significa  “el  directorio  actual.”)  Si  ese  archivo  no  existe, 
Python  va  a buscar  el  modulo  en  /usr/lib/python3.4/site-packages/foo.py.  Si  ese 
archivo  no  existe,  entonces  probara  en  /home/username/djcode/foo.py.  Finalmente, 
si  ese  archivo  no  existe,  Python  lanzara  una  exception  ImportError 

Si  estas  interesado  en  ver  el  valor  de  tu  Python  path,  abre  un  interprete  interactive 
de  Python  y escribe: 

»>  from  future import  print_function 

»>  import  sys 

»>  print  (sys. path) 

De  nuevo,  importamos  la  funcion  print_function()  del  paquete  future  para 
mantener  compatibilidad  entre  Python  2 y 3. 

Generalmente  no  tienes  que  preocuparte  por  asignarle  valores  al  Python  path  - 
Python  y Django  se  encargan  automaticamente  de  hacer  esas  cosas  por  ti  entre 
bastidores.  (Si  eres  un  poco  curioso,  establecer  el  Python  path  es  una  de  las  primeras 
tareas  que  hace  el  archivo  manage.py). 

Vale  la  pena  discutir  un  poco  mas  la  sintaxis  que  usada  en  el  patron 
"URLpattern",  ya  que  no  es  muy  obvio  el  ejemplo,  si  esta  es  la  primera  vez  que 
tropiezas  con  las  expresiones  regulares: 

■ La  r en  r'Ahola/$'  significa  que  'Ahola/$'  es  una  cadena  de  caracteres  en  crudo 
de  Python.  Esto  permite  que  las  expresiones  regulares  sean  escritas  sin 
demasiadas  sentencias  de  escape. 

■ Puedes  excluir  la  barra  al  comienzo  de  la  expresion  'Ahola/$'  para  que 
coincida  con  /hola/.  Django  automaticamente  agrega  una  barra  antes  de 
toda  expresion.  A primera  vista  esto  parece  raro,  pero  una  URLconf  puede  ser 
incluida  en  otra  URLconf,  y el  dejar  la  barra  de  lado  simplifica  mucho  las 
cosas.  Esto  se  retoma  en  el  capitulo  8. 

■ El  patron  incluye  el  acento  circunflejo  (A)  y el  signo  de  dolar  ($)  estos  son 
caracteres  de  la  expresion  regular  que  tienen  un  significado  especial.  El  acento 
circunflejo  significa  que  “requiere  que  el  patron  concuerde  con  el  inicio  de  la 
cadena  de  caracteres”,  y el  signo  de  dolar  significa  que  “exige  que  el  patron 
concuerde  con  el  fin  de  la  cadena”. 
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■ Este  concepto  se  explica  mejor  con  un  ejemplo.  Si  hubieramos  utilizado  el 
patron  'Ahola/'  (sin  el  signo  de  dolar  al  final),  entonces  cualquier  URL  que 
comience  con  hola/  concordaria,  asi  como  /hola/foo  y /hola/bar,  no  solo 
/hola/.  Del  mismo  modo,  si  dejamos  de  lado  el  caracter  acento  circunflejo 
inicial  ('hola/$'),  el  patron  coincidiria  con  cualquier  URL  que  termine  con 
hola/,  asi  como  /foo/ bar /time/.  Por  lo  tanto,  usamos  tanto  el  acento 
circunflejo  como  el  signo  de  dolar  para  asegurarnos  que  solo  la  URL  /hola/ 
coincida.  Nada  mas  y nada  menos. 

■ La  mayor  parte  de  los  patrones  URL,  empiezan  con  el  acento  circunflejo  (A)  y 
terminan  con  el  signo  de  dolar  ($),  esto  es  bueno,  ya  que  permite  una  mayor 
flexibilidad  para  realizar  concordancias  mas  complejas  y exactas. 


Expresiones  regulares 


Las  Expresiones  Regulares  (o  regexes)  son  la  forma  compacta  de  especificar 
patrones  en  un  texto.  Aunque  las  URLconfs  de  Django  permiten  el  uso  de  regexes 
arbitrarias  para  tener  un  potente  sistema  de  definition  de  URLs,  probablemente 
en  la  practica  no  utilices  mas  que  un  par  de  patrones  regex.  Esta  es  una 
pequena  selection  de  patrones  comunes: 


Simbolo 

. (punto) 
\d 

[A-Z] 

[a-z] 

[A-Za-z] 


[A/]  + 
? 


{1,3} 


Coincide  con 

Cualquier  caracter 
Cualquier  digito 

Cualquier  caracter,  A-Z  (mayusculas) 

Cualquier  caracter,  a-z  (minusculas) 

Cualquier  caracter,  a-z  (no  distingue  entre  mayuscula  y minuscula) 
Una  o mas  ocurrencias  de  la  expresion  anterior  (ejemplo,  \d+ 
coincidira  con  uno  o mas  digitos) 

Cualquier  caracter  excepto  la  barra  o diagonal. 

Cero  o una  ocurrencia  (ejemplo  \d?  coincidira  con  cero  o un  digito 
Cero  o mas  ocurrencias  de  la  expresion  anterior  (ejemplo,  \d* 
coincidira  con  cero  o mas  digitos) 

Entre  una  y tres  (inclusive)  ocurrencias  de  la  expresion  anterior 
(ejemplo  \d{l,3}  coincidira  con  uno,  dos  o tres  digitos) 


Para  mas  information  acerca  de  las  expresiones  regulares,  mira  el  modulo 
(5)  http://www.djangoproject.eom/r/python/re-module/. 

Quizas  te  preguntes  que  pasa  si  alguien  intenta  acceder  a /hola.  {sin  poner  la 
segunda  barra  o diagonal).  Porque  no  concuerda  con  el  patron  que  definimos,  sin 
embargo  por  defecto  cualquier  petition  a cualquier  URL  que  no  contenga  una  barra 
final  y que  no  concuerde  con  un  patron,  sera  redireccionado  a la  misma  URL  con  la 
diagonal  final,  siempre  y cuando  la  variable  APPEND_SLASH  tenga  asignado  el  valor 
True.  (APPEND_SLASH,  significa  “Agrega  una  diagonal  al  final”.  Consulta  el  apendice 
D„  si  quieres  ahondar  mas  en  este  tema). 

Si  eres  el  tipo  de  persona  que  le  gusta  que  todas  sus  URL,  contengan  una  barra  al 
final  (como  lo  prefieren  muchos  desarrolladores  de  Django),  todo  lo  que  necesitas  es 
agregar  la  barra  a cada  patron  URL  o asignar  True  a la  variable  APPEND_SLASH.  Si 
prefieres  que  tus  URLs  no  contengan  la  barra  o si  quieres  decidir  esto  en  cada  URL, 
agrega  False  a la  variable  APPEND_SLASH  y pon  las  barras  en  tus  patrones  URL 
respectivamente,  como  lo  prefieras. 

La  otra  cosa  que  debes  observar  acerca  de  las  URLconf  es  que  hemos  pasado  la 
funcion  vista  hola  como  un  objeto,  sin  llamar  a la  funcion.  Esto  es  una  caracteristica 
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de  Python  (y  otros  lenguajes  dinamicos):  las  funciones  son  objetos  de  primera  clase, 
lo  cual  significa  que  puedes  pasarias  como  cualquier  otra  variable.  jQue  bueno!  ^no? 

Para  probar  nuestros  cambios  en  la  URLconf,  inicia  el  servidor  de  desarrollo  de 
Django,  como  hiciste  en  el  capitulo  2,  ejecutando  el  comando  python  manage.py 
runserver  (Si  no  lo  tenias  corriendo.)  El  servidor  de  desarrollo  automaticamente 
detecta  los  cambios  en  tu  codigo  de  Python  y recarga  de  ser  necesario,  asi  no  tienes 
que  reiniciar  el  servidor  al  hacer  cambios).  El  servidor  esta  corriendo  en  la  direction 
http:/ / 127. 0.0. 1:8000/,  entonces  abre  tu  navegador  web  y ve  a la  pagina 
http://127.0.0.1:8000/hola/. 

Deberias  ver  la  salida  de  tu  vista  de  Django,  con  el  texto  “Hola  mundo”,  en  un  tono 
azul. 


■■  ® 127.0.0.1;8000/hola/  v C | [ P ☆ S 4-  ft 

jHola  Mundo! 


imagen  3.1  Pagina  “hola  mundo”,  creada  con  Django. 
jEnhorabuena!  Idas  creado  tu  primera  pagina  Web  hecha  con  Django. 


Algunas  notas  rapidas  sobre  errores  404 

En  las  URLconf  anteriores,  hemos  definido  un  solo  patron  URL:  el  que  maneja  la 
peticion  para  la  URL  /hola/.  iQue  pasaria  si  se  solicita  una  URL  diferente? 

Para  averiguarlo,  prueba  ejecutando  el  servidor  de  desarrollo  Django  e intenta 
acceder  a una  pagina  Web  como  http:// 127. 0.0.1:8000/adios/  o 
http://127.0.0.1:8000/hola/directorio/  , o mejor  como  http:// 127.0.0. 1:8000/  (la 
“raiz”  del  sitio).  Deberias  ver  el  mensaje  “Page  not  found”  (“Pagina  no  encontrada”, 
ver  la  Figura  siguiente).  Es  linda,  jno?  A la  gente  de  Django  seguro  le  gustan  los 
colores  pastel. 


127.0.0.1:8000/adios  GT  | P -(f  (§  4-  -ft 


Pagina  no  encontrada  <404) 

Peticion:  GET 

URL  pedida:  http://1 27.0.0. 1:8000/adios 

Usando  la  URLconf  definida  enmisitio.uris,  Django  intento  usar  los  siguientes  patrones,  en  este  orden: 

1.  ''hola/? 

La  actual  URL,  adios,  No  coincide  con  ninguna  de  las  URL  pedidas. 

Estas  viendo  este  mensaje,  porque  el  archivo  de  configuraciones  de  Django,  esta  ajustado  en  debug  = True.  Cambialo  a False,  y Django  mostrara  una 
tipica  pagina  404. 


Imagen  3.2  Pagina  de  error  404 

Django  muestra  este  mensaje  porque  solicitaste  una  URL  que  no  esta  definida  en 
tu  URLconf. 

La  utilidad  de  esta  pagina  va  mas  alia  del  mensaje  basico  de  error  404;  nos  dice 
tambien,  que  URLconf  utilizo  Django  y todos  los  patrones  de  esa  URLconf.  Con  esa 
information,  tendriamos  que  ser  capaces  de  establecer  porque  la  URL  solicitada 
lanzo  un  error  404. 
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Naturalmente,  esta  es  information  importante  solo  destinada  a ti,  el 
administrador  Web.  Si  esto  fuera  un  sitio  en  production  alojado  en  Internet,  no 
quisieramos  mostrar  esta  information  al  publico.  Por  esta  razon,  la  pagina  “Page  not 
found”  es  solo  mostrada  si  nuestro  proyecto  en  Django  esta  en  modo  de  depuracion 
[debug  mode).  Explicaremos  como  desactivar  este  modo  mas  adelante.  Por  ahora, 
solo  diremos  que  todos  los  proyectos  estan  en  modo  de  depuracion  cuando  los 
creamos,  y si  el  proyecto  no  lo  estuviese,  se  retornaria  una  respuesta  diferente. 

Algunas  notas  rapidas  sobre  la  rai'z  del  sitio 

Como  explicamos  en  la  section  anterior,  si  estas  viendo  un  mensaje  de  error  404  al 
acceder  a la  raiz  de  tu  sitio  http:/ / 127. 0.0. 1:8000/.  Es  porque  Django  no  agrega 
magicamente  nada  y las  URLs  no  son  un  caso  especial.  Si  quieres  asignar  un  patron  a 
la  raiz  de  tu  sito,  necesitas  crear  una  vista  y agregarla  a la  URL  conf. 

Cuando  estes  listo  para  implementar  una  vista  para  la  raiz  de  tu  sitio,  usa  el  patron 
’A$’,  el  cual  coincidira  con  cualquier  cadena  vacia.  Por  ejemplo  supongamos  que 
creas  una  vista  llamada  'raiz'  la  cual  quieres  usar  como  raiz  de  tu  sitio: 

from  django.conf.urls  import  url 
from  misitio. views  import  raiz,  hola 

urlpatterns  = [ 
url(r'A$',  raiz), 
url(r'Ahola/$',  hola), 

# ... 

] 


Como  procesa  una  peticion  Django 

Antes  de  crear  una  segunda  vista,  hagamos  una  pausa  para  aprender  un  poco  mas 
sobre  la  forma  en  Django  trabaja.  Especialmente  analicemos  cuando  recibimos  el 
mensaje  “Hola  mundo”,  al  visitar  la  pagina  http:// 127. 0.0.1:8000/hola/  en  el 
navegador  web,  esto  es  lo  que  Django  hace  tras  bambalinas. 

Todo  comienza  cuando  el  comando  manage.py  runserver  importa  un  archivo 
llamado  settings.py  desde  el  directorio  interno  misitio.  Este  archivo  contiene  todo  tipo 
de  configuraciones  opcionales  para  esta  instancia  de  Django  en  particular,  todas 
estas  configuraciones  estan  en  mayusculas:  TEMPLATE_DIRS,  DATABASES.  Sin 
embargo  una  de  las  configuraciones  mas  importantes  es  ROOT_URLCONF.  La 
variable  ROOT_URLCONF  le  dice  a Django  que  modulo  de  Python  deberia  usar  para 
la  URLconf  de  este  sitio  Web. 

^Recuerdas  cuando  django-admin.py  startproject  creo  el  archivo  settings.py  y el 
archivo  urls.py?  Bueno,  el  archivo  settings.py  generado  automaticamente  contenia 
una  variable  ROOT_URLCONF  que  apunta  al  urls.py  generado  automaticamente. 
jQue  conveniente!  Si  abres  el  archivo  settings.py;  encontraras  algo  como  esto: 

R00T_URLC0NF  = ' misitio  . u rls  ' 

Este  corresponde  al  archivo  misitio /urls.py. 

Cuando  llega  una  peticion  -digamos,  una  peticion  a la  URL  /hola/  Django  carga  la 
URLconf  apuntada  por  la  variable  ROOT_URLCONF.  Luego  comprueba  cada  uno  de 
los  patrones  de  URL,  en  la  URLconf  en  orden,  comparando  la  URL  solicitada  con  un 


30  CAPITULO  3 LOS  PRINCIPIOS  BASICOS  DE  LAS  PAGINAS  WEB  DINAMICAS 


patron  a la  vez,  hasta  que  encuentra  uno  que  coincida.  Cuando  encuentra  uno  que 
coincide,  llama  a la  funcion  de  vista  asociada  con  ese  patron,  pasando  un  objeto 
HttpRequest  como  primer  parametro  de  la  funcion.  (Veremos  mas  de  HttpRequest 
mas  adelante). 

Como  vimos  en  el  ejemplo  anterior,  la  funcion  de  vista  es  responsable  de  retornar 
un  objeto  HttpResponse.  Una  vez  que  hace  esto,  Django  hace  el  resto,  convierte  el 
objeto  Python  en  una  apropiada  respuesta  Web,  que  contiene  las  cabeceras  HTTP  y 
un  cuerpo  (es  decir  el  contenido  de  la  pagina  Web.) 

En  resumen,  el  algoritmo  sigue  los  siguientes  pasos: 

1.  Se  recibe  una  petition,  por  ejemplo  a /hola/ 

2.  Django  determina  la  URLconf  a usar,  buscando  la  variable  ROOT_URLCONF 
en  el  archivo  de  configuraciones. 

3.  Django  busca  todos  los  patrones  en  la  URLconf  buscando  la  primera 
coincidencia  con  /hola/. 

4.  Si  encuentra  uno  que  coincida,  llama  a la  funcion  vista  asociada. 

5.  La  funcion  vista  retorna  una  HttpResponse. 

6.  Django  convierte  el  HttpResponse  en  una  apropiada  respuesta  HTTP,  la  cual 
convierte  en  una  pagina  Web. 

Ahora  ya  conoces  lo  basico  sobre  como  hacer  paginas  Web  con  Django.  Es 
muy  sencillo,  realmente  - solo  tienes  que  escribir  funciones  de  vista  y 
relacionarlas  con  URLs  mediante  URLconfs.  Podrias  pensar  que  es  lento  enlazar 
las  URL  con  funciones  usando  una  serie  de  expresiones  regulares,  epero  te 
sorprenderas...! 


Tu  segunda  Vista:  Contenido  dinamico 

El  ejemplo  anterior,  “Hola  mundo”  fue  bastante  instructivo  y demostro  la  forma 
basica  en  la  que  trabaja  Django,  sin  embargo  no  es  un  buen  ejemplo  de  una  pagina 
Web  dinamica  porque  el  contenido  siempre  es  el  mismo.  Cada  vez  que  visitemos 
/hola/,  veremos  la  misma  cosa;  por  lo  que  esta  pagina,  es  mas  un  archivo  estatico 
HTML. 

Para  nuestra  segunda  vista,  crearemos  algo  mas  dinamico  y divertido.  Una  pagina 
Web  que  muestre  la  fecha  y la  hora  actual.  Este  es  un  buen  ejemplo  de  una  pagina 
dinamica,  porque  el  contenido  de  la  misma  no  es  estatico  - ya  que  los  contenidos 
cambian  de  acuerdo  con  el  resultado  de  un  calculo  (en  este  caso,  el  calculo  de  la  hora 
actual).  Este  segundo  ejemplo  no  involucra  una  base  de  datos  o necesita  de  entrada 
alguna,  solo  muestra  la  salida  del  reloj  interno  del  servidor.  Es  un  poco  mas 
instructivo  que  el  ejemplo  anterior  y demostrara  algunos  conceptos  nuevos. 

La  vista  necesita  hacer  dos  cosas:  calcular  la  hora  actual  y la  fecha,  para  retornar 
una  respuesta  HttpResponse  que  contenga  dichos  valores.  Si  tienes  un  poco  de 
experiencia  usando  Python,  ya  sabes  que  Python  incluye  un  modulo  llamado 
datetime,  encargado  de  calcular  fechas. 

Esta  es  la  forma  en  que  se  usa: 

»>  from  future import  print_function 

»>  import  datetime 

»>  ahora  = datetime. datetime. now() 

»>  ahora 

datetime. datetime(2014-10-16  17:36:30.493000) 

»>  print  (ahora) 
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2014-10-16  17:06:30.493000 

El  ejemplo  es  bastante  simple  y Django  no  necesita  hacer  nada.  Ya  que  es  solo 
codigo  Python.  (Es  necesario  hacer  enfasis  en  que  el  codigo  usado,  “es  solo  Python” 
comparandolo  especificamente  con  el  codigo  Django  que  usaremos.  Para  que  no  solo 
aprendas  Django,  sino  no  para  que  puedas  aplicar  tu  conocimiento  Python  en  otros 
proyectos,  no  necesariamente  usando  Django) 

Para  crear  esta  pagina,  crearemos  una  funcion  de  vista,  que  muestre  la  fecha  y la 
hora  actual,  por  lo  que  necesitamos  anclar  la  declaration  datetime.datetime.now() 
dentro  de  la  vista  para  que  la  retorne  como  una  respuesta  ElttpResponse. 

Esta  es  la  vista  que  retorna  la  fecha  y hora  actual,  como  un  documento  E1TML: 

from  django.http  import  HttpResponse 
import  datetime 

def  fecha_actual(request): 

ahora  = datetime. datetime. now() 

html  = <html><body><hl>Fecha:</hl><h3>%s<h/3></body></html>"  % ahora 
return  HttpResponse(html) 

Asi  como  la  funcion  hola,  que  creamos  en  la  vista  anterior,  la  funcion  fecha_actual 
deve  de  colocarse  en  el  mismo  archivo  views.py.  Si  estas  siguiendo  el  libro  y 
programando  al  mismo  tiempo,  notaras  que  el  archivo  views.py  ahora  contiene  dos 
vistas.  (Omitimos  el  E1TML  del  ejemplo  anterior  solo  por  claridad  y brevedad). 
Poniendolas  juntas,  veriamos  algo  similar  a esto: 


views . py 


from  django.http  import  HttpResponse 
import  datetime 

def  hola(request): 

return  HttpResponse("Hola  mundo") 

def  fecha_actual(request): 

ahora  = datetime. datetime. now() 

html  = "<html><body><hl>Fecha:</hl><h3>%s<h/3></body></html>"  % ahora 
return  HttpResponse(html) 

Repasemos  los  cambios  que  hemos  hecho  al  archivo  views.py,  para  acomodar  la 
funcion  fecha_actual  en  la  vista. 

■ Hemos  agregado  import  datetime  al  inicio  del  modulo,  el  cual  calcula  fechas 
(Importamos  el  modulo  datetime  de  la  biblioteca  estandar  de  Python)  El 
modulo  datetime  contiene  varias  funciones  y clases  para  trabajar  con  fechas  y 
horas,  incluyendo  una  funcion  que  retorna  la  hora  actual. 

■ La  nueva  funcion  fecha_actual  calcula  la  hora  y la  fecha  actual  y almacena  el 
resultado  en  la  variable  local  ahora. 

■ La  segunda  linea  de  codigo  dentro  de  la  funcion  construye  la  respuesta  HTML 
usando  el  formato  de  cadena  de  caracteres  de  Python.  El  %s  dentro  de  la 
cadena  de  caracteres  es  un  marcador  de  position,  y el  signo  de  porcentaje 
despues  de  la  cadena  de  caracteres,  significa  “Reemplaza  el  %s  por  el  valor  de 
la  variable  ahora.”  La  variable  ahora  es  tecnicamente  un  objeto 
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datetime.datetime,  no  una  cadena,  pero  %s  el  formato  de  cadenas  de 
caracteres  de  Python  lo  convierte  en  algo  asi  como:  “2014-10-16 

17:36:30.493000”.  La  cadena  resultante  sera  transformada  en  HTML  de  esta 
forma:  “<htmlxbody>Hoy  es  2014-10-16  1 7:36:30.493000.  </bodyx/html>”. 
(Si  si  si,  el  HTML  es  invalido,  pero  estamos  tratando  de  mantener  el  ejemplo 
de  forma  simple  y breve). 

■ Por  ultimo,  la  vista  retorna  un  objeto  HttpResponse  que  contiene  la  respuesta 
generada.  Justo  como  en  el  ejemplo:  Hola  mundo. 

Despues  de  agregar  la  funcion  a views.py,  necesitamos  agregar  el  patron  al  archivo 
urls.py  para  decide  a Django  que  maneje  esta  vista.  Algo  como  lo  que  hicimos  con  la 
funcion  hola/ : 


urls .py 


from  django.conf.urls  import  url 

from  misitio.views  import  hola,  fecha_actual 

urlpatterns  = [ 

url(r'Ahola/$',  hola), 
url(r'Afecha/$\  fecha_actual), 

] 


Hemos  hecho  dos  cambios  aqui. 

1.  Primero,  importamos  la  vista  fecha_actual  desde  el  modulo  (misitio/views.py, 
que  en  la  sintaxis  de  import  de  Python  se  traduce  a misitio.views). 

2.  Segundo,  y mas  importante  agregamos  un  nuevo  patron  que  mapea  la  URL 
/fecha/  a la  nueva  funcion  vista  que  hemos  creado,  agregando  la  linea 
url(r'Afecha/$',  fecha_actual).  Esta  linea  hace  referencia  a un  URLpattern  - 
una  tupla  de  Python  en  donde  el  primer  elemento  es  una  expresion  regular 
simple  y el  segundo  elemento  es  la  funcion  de  vista  que  se  usa  para  ese 
patron. 

Una  vez  que  hemos  escrito  la  vista  y actualizado  el  patron  URL,  ejecuta  runserver  y 
visita  la  pagina  http://127.0.0.1:8000/fecha/  en  tu  navegador.  Deberias  poder  ver  la 
fecha  y la  hora  actual. 


ZONA  HORARIA  DE  DJANGO 


Dependiendo  de  tu  computadora,  de  la  fecha  y la  hora,  la  salida  puede  ser  distinta. 
Esto  se  debe  a que  Django  incluye  una  option  TIME_ZONE  que  por  omision  es 
America/Chicago.  Probablemente  no  es  donde  vivas,  por  lo  que  puedes  cambiarlo  en 
tu  archivo  de  configuraciones  settings.py.  Puedes  consultar 

http://en.wikipedia.org/wiki/List_of_tz_zones_by_name,  para  encontrar  una  lista 
completa  de  las  zonas  horario  de  todo  el  mundo. 


URLconfs  y el  acoplamiento  debit 

Ahora  es  el  momento  de  resaltar  una  parte  clave  de  la  filosofia  detras  de  las  URLconf 
y detras  de  Django  en  general:  el  principio  de  acoplamiento  debil  ( loose  coupling). 
Para  explicarlo  de  forma  simple:  el  acoplamiento  debil  es  una  manera  de  disenar 
software  aprovechando  el  valor  de  la  importancia  de  que  se  puedan  cambiar  las 
piezas.  Si  dos  piezas  de  codigo  estan  debilmente  acopladas  ( loosely  coupled)  los 
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cambios  realizados  sobre  una  de  dichas  piezas  va  a tener  poco  o ningun  efecto  sobre 
la  otra. 

Las  URLconfs  de  Django  son  un  claro  ejemplo  de  este  principio  en  la  practica.  En 
una  aplicacion  Web  de  Django,  la  definition  de  la  URL  y la  funcion  de  vista  que  se 
llamara  estan  debilmente  acopladas;  de  esta  manera,  la  decision  de  cual  debe  ser  la 
URL  para  una  funcion,  y la  implementacion  de  la  funcion  misma,  residen  en  dos 
lugares  separados.  Esto  permite  el  desarrollo  de  una  pieza  sin  afectar  a la  otra. 

En  contraste,  otras  plataformas  de  desarrollo  Web  acoplan  la  URL  con  el  programa. 
En  las  tipicas  aplicaciones  PHP  (http://www.php.net/),  por  ejemplo,  la  URL  de  tu 
aplicacion  es  designada  por  donde  colocas  el  codigo  en  el  sistema  de  archivos.  En 
versiones  anteriores  del  framework  Web  Python  CherryPy 
(http://www.cherrypy.org/)  la  URL  de  tu  aplicacion  correspondia  al  nombre  del 
metodo  donde  residia  tu  codigo.  Esto  puede  parecer  un  atajo  conveniente  en  el  corto 
plazo,  pero  puede  tornarse  inmanejable  a largo  plazo. 

Por  ejemplo,  consideremos  la  funcion  de  vista  que  escribimos  antes,  la  cual  nos 
mostraba  la  fecha  y la  hora  actual.  Si  quieres  cambiar  la  URL  de  tu  aplicacion  - 
digamos,  mover  desde  /fecha/  a /otrafecha/  - puedes  hacer  un  rapido  cambio  en  la 
URLconf,  sin  preocuparte  acerca  de  la  implementacion  subyacente  de  la  funcion. 
Similarmente,  si  quieres  cambiar  la  funcion  de  vista  - alterando  la  logica  de  alguna 
manera  - puedes  hacerlo  sin  afectar  la  URL  a la  que  esta  asociada  tu  funcion  de  vista. 
Ademas,  si  quisieramos  exponer  la  funcionalidad  de  fecha  actual  en  varias  URL 
podriamos  hacerlo  editando  el  URLconf  con  cuidado,  sin  tener  que  tocar  una  sola 
linea  de  codigo  de  la  vista  asi. 

urlpatterns  = [ 

url(r'Ahola/$',  hola), 
url(r'Afecha/$',  fecha_actual), 
url(r'Aotrafecha/$',  fecha_actual), 

] 


Este  es  el  acoplamiento  debil  en  action.  Continuaremos  exponiendo  ejemplos  de 
esta  importante  filosofia  de  desarrollo  a lo  largo  del  libro. 

Tu  tercera  vista:  contenido  dinamico 

En  la  vista  anterior  fecha_actual,  el  contenido  de  la  pagina  - la  fecha/hora  actual  - 
eran  dinamicas,  pero  la  URL  (/fecha/)  era  estatica.  En  la  mayoria  de  las  aplicaciones 
Web,  sin  embargo,  la  URL  contiene  parametros  que  influyen  en  la  salida  de  la  pagina. 
Por  ejemplo  en  una  libreria  en  linea,  cada  uno  de  los  libros  tendria  una  URL  distinta 
asi:  /libro/243/ y /libro/81196/. 

Siguiendo  con  los  ejemplos  anteriores,  vamos  a crear  una  tercera  vista  que  nos 
muestre  la  fecha  y hora  actual  con  un  adelanto  de  ciertas  horas.  El  objetivo  es  montar 
un  sitio  en  la  que  la  pagina  /fecha/mas/1/  muestre  la  fecha/hora,  una  hora  mas 
adelantada,  la  pagina  /fecha/mas/2/  muestre  la  fecha/hora,  dos  horas  mas 
adelantada,  la  pagina  /fecha/ mas  131  muestre  la  fecha/hora,  tres  horas  mas 
adelantada,  y asi  sucesivamente. 

A un  novato  se  le  ocurriria  escribir  una  funcion  de  vista  distinta  para  cada  adelanto 
de  horas,  lo  que  resultaria  en  una  URLconf  como  esta: 

urlpatterns  = [ 

url(r'Afecha/$',  fecha_actual), 
ulr(r’Afecha/mas/l/$',  una_hora_adelante), 
url(r'Afecha/mas/2/$',  dos_horas_adelante), 
url(r'Afecha/mas/3/$',  tres_horas_adelante), 
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url  (r'Afecha/mas/4/$',  cuatro_horas_adelante), 

] 


Claramente,  esta  linea  de  pensamiento  es  incorrecta.  No  solo  porque  producira 
redundancia  entre  las  funciones  de  vista,  sino  tambien  la  aplicacion  estara  limitada  a 
admitir  solo  el  rango  del  horario  deflnido  - uno,  dos,  tres  o cuatro  horas.  Si,  de 
repente,  quisieramos  crear  una  pagina  que  mostrara  la  hora  cinco  horas  adelantada, 
tendriamos  que  crear  una  vista  distinta  y una  linea  URLconf,  perpetuando  la 
duplicacion  y la  demencia.  Aqui  necesitamos  algo  de  abstraccion. 

Algunas  palabras  acerca  de  las  URLs  bonitas 

Si  tienes  experiencia  en  otra  plataforma  de  diseno  Web,  como  PHP  o Java,  es  posible 
que  estes  pensado,  “jOye,  usemos  un  parametro  como  una  cadena  de  consulta!”,  algo 
asi  como  /fecha/mas?horas=3,  en  el  cual  la  hora  sera  designada  por  el  parametro 
hora  de  la  cadena  de  consulta  de  la  URL  (la  parte  a continuacion  de  ?). 

Con  Django  puedes  hacer  eso  (pero  te  diremos  como  mas  adelante,  si  es  que 
realmente  quieres  saberlo),  pero  una  de  las  filosofias  del  nucleo  de  Django  es  que  las 
URLs  deben  ser  bonitas.  La  URL  /fecha/mas/3  es  mucho  mas  limpia,  mas  simple, 
mas  legible,  mas  facil  de  dictarse  a alguien  y ...  Justamente  mas  elegante  que  su 
homologa  forma  de  cadena  de  consulta. 

Las  URLs  bonitas  son  un  signo  de  calidad  en  las  aplicaciones  Web. 

El  sistema  de  URLconf  que  usa  Django  estimula  a generar  URLs  agradables, 
haciendo  mas  facil  el  usarlas  que  el  no  usarlas. 

Comodines  en  los  patrones  URL 

Continuando  con  el  diseno  de  nuestra  aplicacion,  pongamosle  un  comodin  al  patron 
URL,  para  que  maneje  las  horas  de  forma  arbitraria.  Como  ya  se  menciono 
anteriormente,  un  patron  URL  es  una  expresion  regular;  asi  que  podemos  usar  una 
expresion  regular  \d+  como  patron,  para  que  coincida  con  uno  o mas  digitos: 

urlpatterns  = [ 

# ... 

url(r'Afecha/mas/\d+/$',  horas_adelante), 

# ... 

] 


Este  nuevo  patron  coincidira  con  cualquier  URL  que  sea  del  tipo  /fecha/mas/2/, 
/fecha/mas/25/,  o tambien  /fecha/mas/ 100000000000/.  Bueno,  ahora  que  lo  pienso, 
podemos  limitar  el  lapso  maximo  de  horas  a 99.  Eso  significa  que  queremos  tener 
numeros  de  uno  o dos  digitos  en  la  sintaxis  de  las  expresiones  regulares,  con  lo  que 
nos  quedaria  asi  \d{l,2}: 

url(r'Afecha/mas/\d{l,2}/$',  horas_adelante), 

(Hemos  usado  el  caracter  #...  para  comentar  los  patrones  anteriores,  solo  por 
brevedad). 
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Nota:  Cuando  construimos  aplicaciones  Web,  siempre  es  importante  considerar  el 
caso  mas  descabellado  posible  de  entrada,  y decidir  si  la  aplicacion  admitira  o no  esa 
entrada.  Aqui  hemos  limitado  a los  exagerados  reconociendo  lapsos  de  hasta  99 
horas.  Y,  por  cierto,  Los  Limitadores  exagerados,  aunque  largo,  seria  un  nombre 
fantastico  para  una  banda  musical. 


Ahora  designaremos  el  comodrn  para  la  URL,  necesitamos  una  forma  de  pasar  esa 
information  a la  funcion  de  vista,  asi  podremos  usar  una  sola  funcion  de  vista  para 
cualquier  adelanto  de  hora.  Lo  haremos  colocando  parentesis  alrededor  de  los  datos 
en  el  patron  URL  que  queramos  guardar.  En  el  caso  del  ejemplo,  queremos  guardar 
cualquier  numero  que  se  anotara  en  la  URL,  entonces  pongamos  parentesis 
alrededor  de  \d{l,2}: 

url(r'Afecha/mas/(\d{l,2})/$',  horas_adelante), 

Si  estas  familiarizado  con  las  expresiones  regulares,  te  sentiras  como  en  casa  aqui; 
estamos  usando  parentesis  para  capturar los  datos  del  texto  que  coincide. 

La  URLconf  final,  incluyendo  las  vistas  anteriores,  hola  y fecha_actual,  nos  quedara 
asi: 


urls .py 


from  django.conf.urls  import  url 

from  misitio. views  import  hola,  fecha_actual,  horas_adelante 

urlpatterns  = [ 

url(r'Ahola/$',  hola), 
url(r'Afecha/$',  fecha_actual), 
url(r'Afecha/mas/(\d{l,2})/$',  horas_adelante), 

] 


Ahora,  vamos  a escribir  la  funcion  vista:  horas_adelante.  La  vista  horas_adelante  es 
muy  similar  a la  vista  fecha_actual,  que  escribimos  anteriormente,  solo  que  con  una 
pequena  diferencia:  tomara  un  argumento  extra,  el  numero  de  horas  a mostrar  por 
adelantado. 

Agrega  al  archivo  views.py  lo  siguiente: 

from  django.http  import  Http404,  HttpResponse 
import  datetime 

def  horas_adelante(request,  offset): 

try: 

offset  = int(offset) 
except  ValueError: 
raise  Http404() 

dt=  datetime. datetime.  now()+datetime.timedelta(hours=offset) 
html  = "<html><body><hl>En  %s  hora(s),  seran:</hl>  <h3> 
%s</h3></bodyx/html>"  % (offset,  dt) 
return  HttpResponse(html) 

Repasemos  el  codigo  anterior  linea  a linea: 

■ Tal  como  hicimos  en  la  vista  fecha_actual,  importamos  la  clase 
django.http. HttpResponse  de  Django  y el  modulo  datetime  de  Python. 
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■ La  funcion  de  vista:  horas_adelante,  toma  riasparametros:  request  y offset. 

o request  es  un  objeto  HttpRequest,  al  igual  que  en  hola  y fecha_actual. 
Lo  diremos  nuevamente:  cada  vista  siempre  toma  un  objeto 
HttpRequest  como  primer  parametro. 

o offset  es  la  cadena  de  caracteres  capturada  por  los  parentesis  en  el 
patron  URL.  Por  ejemplo,  si  la  peticion  URL  fuera  /fecha/mas/3/, 
entonces  el  offset  deberia  ser  la  cadena  de  caracteres  “3”.  Si  la  peticion 
URL  fuera  /fecha/mas/21/,  entonces  el  offset  deberia  ser  la  cadena  de 
caracteres  “21”.  Nota  que  la  cadena  de  caracteres  capturada  siempre 
es  una  cadena  de  caracteres,  no  un  entero,  incluso  si  se  compone  solo 
de  digitos,  como  en  el  caso  '21'. 

■ (Tecnicamente,  siempre  debemos  capturar  objetos  Unicode,  no  bytestrings 
pero  no  te  preocupes  por  esta  distincion  por  el  momento.) 

■ Decidimos  llamar  a la  variable  offset,  pero  puedes  asignarle  el  nombre  que 
quieras,  siempre  que  sea  un  identiflcador  valido  para  Python.  El  nombre  de  la 
variable  no  importa;  todo  lo  que  importa  es  lo  que  contiene  el  segundo 
parametro  de  la  funcion  (luego  de  request).  Es  posible  tambien  usar  una 
palabra  clave,  en  lugar  de  posicion,  como  argumentos  en  la  URLconf.  Eso  lo 
veremos  en  detalle  en  el  capitulo  8. 

■ Lo  primero  que  hacemos  en  la  funcion  es  llamar  a int()  sobre  offset.  Este 
metodo  convierte  el  valor  de  una  cadena  de  caracteres  a entero. 

■ Toma  en  cuenta  que  Python  lanzara  una  excepcion  ValueError  si  se  llama  a la 
funcion  int()  con  un  valor  que  no  puede  convertirse  a un  entero,  como  lo  seria 
la  cadena  de  caracteres  “foo”.  En  este  ejemplo  si  nos  toparamos  con 
ValueError  se  lanzaria  una  excepcion  django.http.Http404,  la  cual  como 
puedes  imaginarte,  da  como  resultado  una  “Pagina  no  encontrada”  o un 
error  404. 

Algun  lector  atento  se  preguntara  jComo  podriamos  levantar  una  excepcion 
ValueError  si  estamos  usando  expresiones  regulares  en  el  patron  URL,  ya  que 
el  patron  (\d{l,2})  captura  solo  digitos  y por  consiguiente  offset  siempre  sera 
una  cadena  de  caracteres  conformada  solo  por  digitos?  La  respuesta  es  que  no 
debemos  preocuparnos  de  atrapar  la  excepcion,  porque  tenemos  la  certeza 
que  la  variable  offset  sera  una  cadena  de  caracteres  conformada  solo  por 
digitos.  Esto  ilustra  otra  ventaja  de  tener  un  URLconf:  nos  provee  un  primer 
nivel  de  validacion  de  entrada.  Por  lo  que  es  una  buena  practica  implementar 
funciones  que  implementen  vistas  que  no  hagan  suposiciones  sobre  sus 
parametros.  ^Recuerdas  el  acoplamiento  debil? 

■ En  la  siguiente  linea  de  la  funcion,  calculamos  la  fecha  actual  y la  hora  y le 
sumamos  apropiadamente  el  numero  de  horas.  Ya  habiamos  visto  el  metodo 
datetime. datetime.nowO  de  la  vista  fecha_actual  el  nuevo  concepto  es  la 
forma  en  que  se  realizan  las  operaciones  aritmeticas  sobre  la  fecha  y la  hora 
creando  un  objeto  datetime.timedelta  y agregandolo  al  objeto 
datetime.datetime.  La  salida  se  almacene  en  la  variable  dt. 

■ Esta  linea  muestra  la  razon  por  la  que  se  llamo  a la  funcion  int()  con  offset.  En 
esta  linea,  calculamos  la  hora  actual  mas  las  hora  que  tiene  offset, 


37 


CAPITULO  3 LOS  PRINCIPIOS  BASICOS  DE  LAS  PAGINAS  WEB  DINAMICAS 


almacenando  el  resultado  en  la  variable  dt.  La  funcion  datetime.timedelta 
requiere  que  el  parametro  hours  sea  un  entero. 

■ A continuacion,  construimos  la  salida  HTML  de  esta  funcion  de  vista,  tal 
como  lo  hicimos  en  la  vista  anterior  fecha_actual,  con  una  pequena  diferencia 
en  la  misma  linea,  y es  que  usamos  el  formato  de  cadenas  de  Python  con  dos 
valores,  no  solo  uno.  Por  lo  tanto,  hay  dos  simbolos  %s  en  la  cadena  de 
caracteres  y la  tupla  de  valores  a insertar  seria:  (offset,  dt) . 

■ Finalmente,  retornamos  el  HttpResponse  del  HTML  - de  nuevo,  tal  como 
hicimos  en  la  vista  fecha_actual. 

Con  esta  funcion  de  vista  y la  URLconf  escrita,  ejecuta  el  servidor  de  desarrollo  de 
Django  (si  no  esta  corriendo),  y visita  http:// 127. 0.0.1:8000/fecha/mas/5/,  para 
verilicar  que  lo  que  hicimos  funciona.  Luego  prueba  con 

http:// 127.0.0.  l:8000/fecha/mas/ 15/. 

Para  terminar  visita  la  pagina  http://127.0.0.1:8000/fecha/mas/100/,  para  verificar 
que  el  patron  en  la  URLconf  solo  acepta  numero  de  uno  o dos  digitos,  Django  deberfa 
mostrar  un  error  en  este  caso  como  “Page  not  found”,  tal  como  vimos  anteriormente 
en  la  seccion  “Errores  404”. 

La  URL  http://127.0.0.1:8000/fecha/mas/  {sin  horas  designadas)  deberia  tambien 
mostrar  un  error  404. 


ORDEN  PARA  PROGRAMAR 


En  este  ejemplo,  primero  escribimos  el  patron  URL  y en  segundo  lugar  la  vista,  pero 
en  el  ejemplo  anterior,  escribimos  la  vista  primero  y luego  el  patron  de  URL.  iQue 
tecnica  es  mejor?  Bien,  cada  programador  es  diferente. 

Si  eres  del  tipo  de  programadores  que  piensan  globalmente,  puede  que  tenga  mas 
sentido  que  escribas  todos  los  patrones  de  URL  para  la  aplicacion  al  mismo  tiempo, 
al  inicio  del  proyecto,  y despues  el  codigo  de  las  funciones  de  vista.  Esto  tiene  la 
ventaja  de  darnos  una  lista  de  objetivos  clara,  y es  esencial  definir  los  parametros 
requeridos  por  las  funciones  de  vista  que  necesitaremos  desarrollar. 

Si  eres  del  tipo  de  programadores  que  les  gusta  ir  de  abajo  hacia  arriba,  tal  vez 
prefieras  escribir  las  funciones  de  vista  primero,  y luego  asociarlas  a URLs.  Esto 
tambien  esta  bien. 

Al  final,  todo  se  reduce  a elegir  que  tecnica  se  amolda  mas  a tu  cerebro.  Ambos 
enfoques  son  validos. 


Como  procesa  una  peticion  Django:  Detalles 

completos 

Ademas  del  mapeo  directo  de  URLs  con  funciones  vista  que  acabamos  de  describir, 
Django  nos  provee  un  poco  mas  de  flexibilidad  en  el  procesamiento  de  peticiones. 

Acabamos  de  ver  el  flujo  tipico  - resolucion  de  una  URLconf  y una  funcion  de  vista 
que  devuelve  un  HttpResponse-  sin  embargo  el  flujo  puede  ser  cortado  o aumentado 
mediante  middleware.  Los  secretos  del  middleware  seran  tratados  en  profundidad  en 
el  capitulol5,  pero  un  esquema  (ver  Figura  3-3)  te  ayudara  conceptualmente  a poner 
todas  las  piezas  juntas. 


En  resumen  esto  es  lo  que  pasa: 
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■ Cuando  llega  una  petition  HTTP  desde  el  navegador,  un  manejador  e spetifico 
a cada  servidor  construye  la  HttpRequest,  para  pasarla  a los  componentes  y 
manejar  el  flujo  del  procesamiento  de  la  respuesta. 

■ El  manejador  luego  llama  a cualquier  middleware  de  Peticion  o Vista 
disponible.  Estos  tipos  de  middleware  son  utiles  para  aumentar  los  objetos 
HttpRequest  asi  como  tambien  para  pro  veer  un  manejo  especial  a 
determinados  tipos  de  peticiones.  En  el  caso  de  que  alguno  de  los  mismos 
retornara  un  HttpResponse  la  vista  no  es  invocada. 

■ Hasta  a los  mejores  programadores  se  le  escapan  errores  [bugs),  pero  el 
middleware  de  exception  ayuda  a aplastarlos.  Si  una  funcion  de  vista  lanza 
una  excepcion,  el  control  pasa  al  middleware  de  Excepcion.  Si  este 
middleware  no  retorna  un  HttpResponse,  la  excepcion  se  vuelve  a lanzar. 

■ Sin  embargo,  no  todo  esta  perdido.  Django  incluye  vistas  por  omision  para 
respuestas  amigables  a errores  404  y 500. 

■ Finalmente,  el  middleware  de  respuesta  es  bueno  para  el  procesamiento 
posterior  a un  HttpResponse  justo  antes  de  que  se  envie  al  navegador  o 
haciendo  una  limpieza  de  recursos  especificos  a una  peticion. 
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Imagen  3.3  El  flujo  completo  de  un  petition  y una  respuesta  en  Django. 
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Paginas  de  error  bonitas  con  Django 

Tomemonos  un  momento  para  admirar  la  bonita  aplicacion  web  que  hemos  creado 
hasta  ahora...  y ahora  jrompamosla!  Introduzcamos  deliberadamente  un  error  de 
Python  en  el  archivo  views.py,  comentando  la  llnea  offset  = int(offset)  de  la  vista 
horas_adelante: 

from  django.http  import  Http404,  HttpResponse 
import  datetime 

def  horas_adelante(request,  offset): 

#try: 

# offset  = int(offset) 

# except  ValueError: 

# raise  Http404() 

dt=  datetime. datetime.  now()+datetime.timedelta(hours=offset) 
html  = "<html><body><hl>En  %s  hora(s),  seran:</hl> 

<h3>  %s</h3></body></html>"  % (offset,  dt) 
return  HttpResponse(html) 

Ejecuta  el  servidor  de  desarrollo  y navega  a:  http://127.0.0.1:8000/fecha/mas/3/. 
Veras  una  pagina  de  error  con  mucha  informacion  significativa,  incluyendo  el 
mensaje  TypeError  mostrado  en  la  parte  superior  de  la  pagina:  "unsupported 
type  for  timedelta  hours  component:  Unicode"  o "string"  en  Python  3. 


^ 127.0.0.1:8000/fecha/mas/3/  C P & # 

TypeError  at  /fecha/mas/3/ 

unsupported  type  for  timedelta  hours  component:  Unicode 

Request  Method:  GET 

Request  URL:  http ://1 27.0.0. 1 :8000/fecha/mas/3/ 

Django  Version:  1.8 

Exception  Type:  TypeError 


Imagen  3.4  Pagina  de  error  bonita  404,  mostrando  informacion  sobre  el  tipo  de  error. 


jQue  ha  ocurrido?  Bueno,  la  funcion  datetime.timedelta  espera  que  el  parametro 
hours  sea  un  entero,  y hemos  comentado  la  linea  de  codigo  que  realiza  la  conversion 
del  offset  a entero. 

Eso  causa  que  datetime.timedelta  lance  un  TypeError.  Este  es  un  tipico  error  que 
todo  programador  comete  en  algun  momento. 

El  punto  especifico  de  este  ejemplo  fue  demostrar  la  pagina  de  error  de  Django. 

Dediquemos  un  momento  a explorar  esta  pagina  y descubrir  las  distintas  piezas  de 
informacion  que  nos  brinda: 

■ En  la  parte  superior  de  la  pagina  se  muestra  la  informacion  clave  de  la 
excepcion:  el  tipo  y cualquier  parametro  de  la  excepcion  (el  mensaje 
"unsupported  type"  en  este  caso),  y el  archivo  en  el  cual  la  excepcion  fue 
lanzada,  ademas  de  el  numero  de  linea  que  contiene  el  error. 

■ Abajo  de  la  informacion  clave  de  la  excepcion,  la  pagina  muestra  la  traza  de 
error  o traceback  de  Python  para  dicha  excepcion.  Esta  es  la  traza  estandar 
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que  se  obtiene  en  el  interprete  de  Python,  solo  que  mas  interactiva  y explicita. 
Por  cada  marco  de  pila,  Django  muestra  el  nombre  del  archivo,  el  nombre  de 
la  funcion/metodo,  el  numero  de  linea  y el  codigo  fuente  de  esa  linea. 

■ Haz  clic  en  la  lmea  de  codigo  (en  gris  oscuro)  para  ver  las  lineas  anteriores  y 
posteriores  a la  linea  erronea,  lo  que  nos  brinda  un  poco  mas  de  contexto. 

■ Haz  clic  debajo  de  “Locals  vars”  (variables  locles)  sobre  el  marco  de  la  pila 
para  ver  la  tabla  completa  de  todas  las  variables  locales  y sus  valores,  este 
marco  muestra  la  position  exacta  del  codigo  en  el  cual  fue  lanzada  la 
excepcion.  Esta  informacion  de  depuration  es  invaluable  y muy  privada. 

■ Observa  que  el  texto  “Switch  to  copy-and-paste  view"  (cambia  a copiar  y 
pegar)  debajo  de  la  cabecera  de  la  traza  de  error.  Haz  clic  en  esas  palabras,  y la 
traza  cambiara  a una  version  que  te  permitira  facilmente  copiar  y pegar.  Usa 
esto  para  cuando  necesites  compartir  la  traza  de  error  de  la  excepcion  con 
otros  o para  obtener  soporte  tecnico  - como  con  los  amables  colegas  que 
encontraras  en  el  canal  de  IRC  o la  lista  de  correo  de  Django. 

■ Debajo  del  boton  “Share  this  traceback  on  a public  Web  site”  (comparte  esta 
traza  de  error  en  un  sitio  publico)  puedes  hacer  clic  en  el  boton,  para  postear 
la  traza  en  un  sitio  publico  como  http://www.dpaste.com/,  donde  podras 
pegarlo  a una  URL,  cada  vez  que  decidas  compartirlo  con  otras  personas. 

■ A continuation,  la  seccion  “Request information" incluye  una  gran  cantidad 
de  informacion  sobre  la  petition  Web  que  provoco  el  error:  informacion  GET 
y POST,  valores  de  las  cookies  y meta  informacion,  asi  como  las  cabeceras 
CGI.  El  apendice  G contiene  una  referencia  completa  sobre  la  informacion 
que  contienen  todos  los  objetos  peticiones. 

■ Mas  abajo,  en  la  seccion  “Settings” se  encuentra  la  lista  de  configuraciones  de 
la  instalacion  de  Django  en  particular.  (El  cual  mencionamos  en 
ROOT_URLCONF)  y mencionaremos  a lo  largo  del  libro.  El  apendice  D,  cubre 
en  detalle  todos  los  ajustes  de  configuration  disponibles.  Por  ahora,  solo  mira 
los  ajustes  para  obtener  una  idea  de  la  informacion  disponible. 

La  pagina  de  error  de  Django  es  capaz  de  mostrar  mas  informacion  en  ciertos 
casos  especiales,  como  por  ejemplo,  en  el  caso  de  error  de  sintaxis  en  las  plantillas.  Lo 
abordaremos  mas  tarde,  cuando  discutamos  el  sistema  de  plantillas  de  Django.  Por 
ahora,  quita  el  comentario  en  la  linea  offset  = int(offset)  para  que  la  funcion  de  vista 
funcione  de  nuevo,  normalmente. 

^Eres  el  tipo  de  programador  al  que  le  gusta  depurar  con  la  ayuda  de  sentencias 
print  cuidadosamente  colocadas?  Puedes  usar  la  pagina  de  error  de  Django  para 
hacer  eso  - sin  usar  la  sentencia  print.  En  cualquier  lugar  de  una  vista, 
temporalmente  puedes  insertar  un  assert  False  para  provocar  una  pagina  de  error. 
Luego,  podras  ver  las  variables  locales  y el  estado  del  programa.  (Hay  maneras  mas 
avanzadas  de  depurar  las  vistas  en  Django,  lo  explicaremos  mas  adelante,  pero  esta 
es  la  forma  mas  rapida  y facil). 


Mira  el  siguiente  ejemplo: 
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def  horas_adelante(request,  offset): 

try: 

offset  = int(offset) 
except  ValueError: 
raise  Http404() 

dt=datetime. datetime.  now()+datetime.timedelta(hours=offset) 

assert  False 

html  = "<html><body><hl>En  %s  hora(s),  seran:</hl><h3> 
%s</h3></bodyx/html>"  % (offset,  dt) 
return  HttpResponse(html) 


Finalmente,  es  obvio  que  la  mayor  parte  de  la  information  mostrada  es  delicada  - 
ya  que  expone  las  entranas  del  codigo  fuente  de  Python,  asf  como  tambien  la 
configuration  de  Django  y seria  una  estupidez  mostrarla  al  publico  en  Internet.  Una 
persona  con  malas  intenciones  podria  usar  esto  para  intentar  aplicar  ingenieria 
inversa  en  la  aplicacion  Web  y hacer  cosas  maliciosas. 

Por  esta  razon,  la  pagina  de  error  es  mostrada  solo  cuando  el  proyecto  esta  en 
modo  depuration.  Explicaremos  como  desactivar  este  modo  mas  adelante.  Por 
ahora,  hay  que  tener  en  claro  que  todos  los  proyectos  de  Django  estan  en  modo 
depuration  automaticamente  cuando  son  creados.  (^Suena  familiar?  Los  errores 
“Page  not  found”,  descriptos  en  la  section  “Errores  404”,  trabajan  de  manera 
similar.) 

^Que  sigue? 

Elasta  ahora  hemos  producido  las  vistas  mediante  codigo  E1TML  dentro  del  codigo 
Python.  Desafortunadamente,  esto  casi  siempre  es  una  mala  idea. 

Pero  por  suerte,  con  Django  podemos  hacer  esto  con  un  potente  motor  de 
plantillas  que  nos  permite  separar  el  diseno  de  las  paginas  del  codigo  fuente 
subyacente.  Nos  sumergiremos  en  el  motor  de  plantillas  de  Django  en  el  proximo 
capitulo 


CAPITULO  4 


El  sistema  de  plantillas 


En  el  capitulo  anterior,  quizas  notaste  algo  extrano  en  la  forma  en  como 

retornamos  el  texto  en  nuestras  vistas  de  ejemplos.  Ya  que  el  HTML  fue  codificado1 
directamente  en  nuestro  codigo  Python,  asi: 

def  fecha_actual(request): 

ahora  = datetime. datetime. now() 

html  = <html><body><hl>Fecha:</hl><h3>%s<h/3></body> 

</html>"  % ahora 
return  HttpResponse(html) 

Aunque  esta  tecnica  fue  conveniente  para  explicar  la  forma  en  que  trabajan  las 
vistas,  no  es  buena  idea  codificar,  mezclar  e incrustar  directamente  el  HTML  en  las 
vistas,  ya  que  este  convenio  conduce  a problemas  severos: 

■ Cualquier  cambio  en  el  diseno  de  la  pagina  requiere  un  cambio  en  el  codigo 
de  Python.  El  diseno  de  un  sitio  tiende  a cambiar  mas  frecuentemente  que  el 
codigo  de  Python  subyacente,  por  lo  que  serfa  conveniente  si  el  diseno  podria 
ser  cambiado  sin  la  necesidad  de  modificar  el  codigo  Python. 

■ Escribir  codigo  Python  y disenar  HTML  son  dos  disciplinas  diferentes,  y la 
mayoria  de  los  entornos  de  desarrollo  web  profesional  dividen  estas 
responsabilidades  entre  personas  separadas  (o  incluso  en  departamento 
separados).  Disenadores  y programadores  HTML/CSS  no  deberian  tener  que 
editar  codigo  Python  para  conseguir  hacer  su  trabajo;  ellos  deberian  tratar  con 
HTML. 

■ Asimismo,  esto  es  mas  eflciente  si  los  programadores  pueden  trabajar  sobre  el 
codigo  Python  y los  disenadores  sobre  las  plantillas  al  mismo  tiempo,  mas 
bien  que  una  persona  espere  por  otra  a que  termine  de  editar  un  solo  archivo 
que  contiene  ambos:  Python  y HTML. 

Por  esas  razones,  es  mucho  mas  limpio  y mantenible  separar  el  diseno  de  la 
pagina  del  codigo  Python  en  si  mismo.  Podemos  hacer  esto  con  el  sistema  de 
plan  Lilias  de  Django,  el  cual  trataremos  en  este  capitulo. 


Sistema  basico  de  plantillas 

Una  plantilla  de  Django  es  una  cadena  de  texto  que  pretende  separar  la  presentation 
de  un  documento  de  sus  datos.  Una  plantilla  define  rellenos  y diversos  bits  de  logica 


1 N.  del  T.:  hard-coded:(Codificado  en  duro) 
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basica  (esto  es,  etiquetas  de  plantillas)  que  regulan  como  debe  ser  mostrado  el 
documento.  Normalmente,  las  plantillas  son  usadas  para  producir  HTML,  pero  las 
plantillas  de  Django  son  igualmente  capaces  de  generar  cualquier  formato  basado  en 
texto. 

Comencemos  con  una  simple  plantilla  de  ejemplo.  Esta  plantilla  en  Django, 
describe  una  pagina  HTML  que  agradece  a una  persona  por  hacer  un  pedido  de  una 
empresa.  Piensa  en  este  como  un  modelo  de  carta: 

<html> 

<head><title>Orden  de  pedido</title></head> 

<body> 

<hl>Orden  de  pedido</hl> 

<p>Estimado:  { nombre  ; ,</p> 

<p>Gracias  por  el  pedido  que  ordeno  de  la  empresa }}. 

El  pedido  junto  con  la  mercancia  se  enviaran  el 

{{ fecha|date:"F  j,  Y"  }}.</p> 

<p>Esta  es  la  lista  de  productos  que  usted  ordeno:</p> 

<ul> 

{%  for  pedido  in  lista_pedido  %} 

<li>{{  pedido  }}</li> 

{%  endfor  %} 

</ul> 

{%  if  garantia  %} 

<p>La  garantia  sera  incluida  en  el  paquete.</p> 

{%  else  %} 

<p>Lamentablemente  no  ordeno  una  garantia,  por  lo 
que  los  danos  al  producto  corren  por  su  cuenta.</p> 

{%  end  if  %} 

<p>Sinceramente  <br  />  empresa  }}</p> 

</body> 

</html> 

Esta  plantilla  es  un  archivo  HTML  basico  con  algunas  variables  y etiquetas  de 
plantillas  agregadas.  Veamos  paso  a paso,  como  esta  construida: 

■ Cualquier  texto  encerrado  por  un  par  de  Haves  (por  ej.  {{  nombre  }})  es  una 
variable.  Esto  significa  “insertar  el  valor  de  la  variable  a la  que  se  dio  ese 
nombre”.  jComo  especificamos  el  valor  de  las  variables?.  Vamos  a llegar  a eso 
enun  momento. 

■ Cualquier  texto  que  este  rodeado  por  Haves  y signos  de  porcentaje  (por  ej.  {% 
if  garantia  %})  es  una  etiqueta  de  plantilla.  La  definition  de  etiqueta  es 
bastante  amplia:  una  etiqueta  solo  le  indica  al  sistema  de  plantilla  “haz  algo”. 

■ Este  ejemplo  de  plantilla  contiene  dos  etiquetas:  la  etiqueta  {%  for  pedido  in 
lista_pedido  %}  (una  etiqueta  for)  y la  etiqueta  {%  if  garantia  %}  (una  etiqueta 

if). 
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Una  etiqueta  for  actua  como  un  simple  constructor  de  bucle,  dejandote 
recorrer  a traves  de  cada  uno  de  los  items  de  una  secuencia.  Una  etiqueta  if, 
como  quizas  esperabas,  actua  como  una  clausula  logica  “if’.  En  este  caso  en 
particular,  la  etiqueta  comprueba  si  el  valor  de  la  variable  garantia  se  evalua 
como  True.  Si  lo  hace,  el  sistema  de  plantillas  mostrara  todo  lo  que  hay  entre 
{%  if  garantia  %}  y {%  endif  %}.  Si  no,  el  sistema  de  plantillas  no  mostrara  esto. 
Nota  que  la  etiqueta  {%  else  %}  es  opcional. 

■ Finalmente,  el  segundo  parrafo  de  esta  plantilla,  muestra  un  ejemplo  de  un 
filtro,  con  el  cual  puedes  alterar  la  exposition  de  una  variable.  En  este 
ejemplo,  {{  fecha|date:"F  j,  Y" }},  estamos  pasando  la  variable  fecha  por  el  filtro 
date,  pasando  los  argumentos  "F  j,  Y"  al  filtro.  El  filtro  date  formatea  fechas  en 
el  formato  dado,  especificado  por  ese  argumento.  Eos  filtros  se  encadenan 
mediante  el  uso  de  un  caracter  pipe  (|),  como  una  referencia  a las  tuberias  de 
Unix. 

Cada  plantilla  de  Django  tiene  acceso  a varias  etiquetas  y filtros  incorporados, 
algunos  de  los  cuales  seran  tratados  en  las  secciones  siguientes.  El  apendice  E 
contiene  la  lista  completa  de  etiquetas  y filtros,  es  una  buena  idea  familiarizarse  con 
estas  etiquetas  y filtros,  para  aprender  a usarlos  e incorporarlos  en  tus  propios 
proyectos.  Tambien  es  posible  crear  tus  propios  filtros  y etiquetas,  los  cuales 
cubriremos  en  el  capitulo  9. 

Usando  el  sistema  de  plantillas 

Sumerjamonos  por  un  rato  en  el  sistema  de  plantillas,  para  entender  la  forma  en  que 
trabajan  -por  ahora  no  las  integraremos  en  las  vistas  que  creamos  en  el  capitulo 
anterior. 

El  objetivo  sera  mostrar  como  trabaja  el  sistema  de  plantillas, 
independientemente  del  resto  de  Django  (Veamoslo  de  otra  forma:  normalmente 
usariamos  el  sistema  de  plantillas  dentro  de  una  vista,  sin  embargo  lo  que  queremos 
dejar  muy  en  claro,  es  que  el  sistema  de  plantillas  es  solo  una  libreria  de  codigo 
Python,  que  se  puede  utilizar  en  cualquier^de,  no  solo  en  las  vista  de  Django.) 

Esta  es  la  forma  basica,  en  la  que  podemos  usar  el  sistema  de  plantillas  de  Django 
en  codigo  Python. 

1.  Crea  un  objeto  Template  pasandole  el  codigo  en  crudo  de  la  plantilla  como 
una  cadena. 

2.  Llama  al  metodo  render!)  del  objeto  Template  con  un  conjunto  de  variables  (o 
sea,  el  contexto).  Este  retorna  una  plantilla  totalmente  renderizada  como  una 
cadena  de  caracteres,  con  todas  las  variables  y etiquetas  de  bloques  evaluadas 
de  acuerdo  al  contexto. 

Usando  codigo,  esta  es  la  forma  que  podria  verse,  solo  inicia  el  interprete 
interactive  con:  python  manage.py  shell: 

»>  from future import  print_fu notion 

»>  from  django  import  template 

»>  t = template. Template('Mi  nombre  es  {{  nombre  }}.') 

»>  c = template. Context({'nombre':  'Adrian'}) 

»>  print  (t.render(c)) 

Mi  nombre  es  Adrian. 

»>  c = template. Context({'nombre':  'Fred'}) 
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»>  print  (t.render(c)) 

Mi  nombre  es  Fred. 

Las  siguientes  secciones  describen  cada  uno  de  los  pasos  con  mayor  detalle. 

Creacion  de  objetos  Template 

La  manera  sencilla  de  crear  objetos  Template  es  instanciarlos  directamente.  La  clase 
Template  se  encuentra  en  el  modulo  django.template,  y el  constructor  toma  un 
argumento,  el  codigo  en  crudo  de  la  plantilla.  Vamos  a sumergirnos  en  el  interprete 
interactivo  de  Python  para  ver  como  funciona  este  codigo. 

En  el  directorio  del  proyecto  misitio,  que  creamos  con  el  comando  django- 
admin.py  startproject  (Cubierto  en  el  capitulo  2)  tipea:  python  manage.py  shell  para 
iniciar  el  interprete  interactivo. 


UN  INTERPRETE  DE  PYTHON  ESPECIAL 


Si  has  usado  Python  antes,  tal  vez  te  sorprenda  que  ejecutemos  python 
manage.py  shell  en  lugar  de  solo  python  que  inicia  el  interprete  interactivo, 
pero  debemos  decirte  que  el  comando  manage.py  shell  tiene  una  importante 
diferencia:  antes  de  iniciar  el  interprete,  le  pregunta  a Django  cual  archivo  de 
configuraciones  usar,  el  cual  incluye  ajustes,  como  la  ruta  al  sistema  de 
plantillas,  sin  estos  ajustes  no  podras  usarlo,  a menos  que  los  importes 
manualmente. 

Si  eres  curioso,  esta  es  la  forma  en  que  trabaja  Django  tras  bastidores. 
Primero  busca  la  variable  de  entorno  llamada  DJANGO_SETTINGS_MODULE, 
la  cual  deberia  encontrarse  en  la  ruta  de  importation  del  archivo  settings.py. 
Por  ejemplo,  puede  ser  DJANGO_SETTINGS_MODULE  o 'misitio. settings', 
asumiendo  que  misitio  este  en  la  ruta  de  busqueda  de  Python  (Python  path). 

Cuando  ejecutas  manage.py  shell,  el  comando  se  encarga  de  configurar 
DJANGO_SETTINGS_MODULE  por  ti.  Es  por  ello  que  te  animamos  a usar 
manage.py  shell,  en  estos  ejemplos  a fin  de  reducir  la  cantidad  de  ajustes  y 
configuraciones  que  tengas  que  hacer. 

Django  tambien  puede  usar  IPython  o b python , si  estan  instalados,  para 
iniciar  un  interprete  interactivo  mejorado,  el  cual  agrega  funcionalidades 
extras  al  simple  interprete  interactivo  piano  por  defecto. 

Si  tienes  instalados  ambos,  y quieres  elegir  entre  usar  IPython  o bpython 
como  interprete,  necesitas  especificarlo  con  la  option  -i  o —interface  de  esta 
forma: 


iPython: 


django-admin.py  shell  -i  ipython 
django-admin.py  shell  --interface  ipython 


bpython: 


django-admin.py  shell  -i  bpython 
django-admin.py  shell  -interface  bpython 


Para  forzar  al  interprete  a usar  el  interprete  interactivo  “piano”  usa: 


django-admin.py  shell  -plain 


Comencemos  con  algunos  fundamentos  basicos  del  sistema  de  plantillas: 
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»>  from future import  print_fu notion 

»>  from  django. template  import  Template 
»>  t = Template('Mi  nombre  es  {{  nombre  }}.') 

»>  print  (t) 

Si  lo  estas  siguiendo  interactivamente,  veras  algo  como  esto: 

<django . template . Template  object  at  0xb7d5f24c> 

Ese  0xb7d5f24c  sera  distinto  cada  vez,  y realmente  no  importa;  es  la  forma  simple 
en  que  Python  “identifica”  un  objeto  de  Template. 

Cuando  creas  un  objeto  Template,  el  sistema  de  plantillas  compila  el  codigo  en 
crudo  a uno  interno,  de  forma  optimizada,  listo  para  renderizar.  Pero  si  tu  codigo  de 
plantilla  incluye  errores  de  tipo  sintaxis,  la  llamada  a TemplateO  causara  una 
excepcion  TemplateSyntaxError: 

»>  from future import  print_fu notion 

»>  from  django. template  import  Template 
»>  t = Template('{%  notatag  %}  j 

El  termino  “block  tag”  “etiqueta  de  bloque”  hace  referencia  a {%  notatag  %}. 
“Etiqueta  de  plantilla”  y “bloque  de  plantilla”  son  sinonimos. 

El  sistema  lanza  una  excepcion  TemplateSyntaxError  por  alguno  de  los  siguientes 
casos: 


■ Bloques  de  etiquetas  invalidos 

■ Argumentos  invalidos  para  una  etiqueta  valida 

■ Filtros  invalidos 

■ Argumentos  invalidos  para  filtros  validos 

■ Sintaxis  invalida  de  plantilla 

■ Etiquetas  de  bloque  sin  cerrar  (para  etiquetas  de  bloque  que  requieran  la 
etiqueta  de  cierre) 

Renderizar  una  plantilla 

Una  vez  que  tienes  un  objeto  Template,  le  puedes  pasar  datos  brindandole  un 
contexto.  Un  contexto  es  simplemente  un  conjunto  de  variables  y sus  valores 
asociados.  Una  plantilla  usa  estas  variables  para  llenar  y evaluar  estas  etiquetas  de 
bloque. 

Un  contexto  es  representado  en  Django  por  la  clase  Context,  esta  se  encuentra  en 
el  modulo  django.template.  Su  constructor  toma  un  argumento  opcional:  un 
diccionario  que  mapea  nombres  de  variables  con  valores.  Llama  al  metodo  renderO 
del  objeto  Template  con  el  contexto  para  “llenar”  la  plantilla: 

»>  from future import  print_function 

»>  from  django.template  import  Context,  Template 
»>  t = Template(  Mi  nombre  es  {{  nombre  }}.") 

»>  c = Context({"nombre":  "Estefanfa"}) 

»>  t.render(c) 

'Mi  nombre  es  Estefanfa.' 

Una  cosa  que  debemos  apuntar  aqui,  es  que  el  valor  de  retorno  de  t.render(c)  es  un 
objeto  Unicode  -No  una  cadena  normal  de  Python-.  Como  sabes  podemos  usar  la 
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“u”  al  inicio  de  la  cadena  para  usar  objetos  Unicode  en  Python  2,  sin  embargo  en 
python3  esto  no  es  necesario,  ya  que  soporta  nativamente  objetos  Unicode.  Sin 
embargo  no  esta  de  mas  decirte  que  Django  tambien  soporta  nativamente  datos 
Unicode  en  lugar  de  cadenas  normales  en  todo  el  framework.  Si  comprendes  las 
repercusiones  de  esto,  estaras  agradecido  por  las  cosas  sofisticadas  que  hace  Django 
tras  bastidores,  para  facilitarte  el  trabajo. 

Si  no  las  comprendes,  no  te  preocupes  por  ahora;  solo  debes  saber  que  Django 
hace  que  el  soporte  Unicode  sea  indoloro  para  tus  aplicaciones,  para  que  puedan 
soportar  una  gran  variedad  de  caracteres,  que  van  mas  alia  del  basico  “A-Z”  del 
idioma  ingles. 


DICCIONARIOS  Y CONTEXTOS 


Un  diccionario  en  Python  es  un  mapeo  entre  Haves  conocidas  y valores  de  variables. 

Un  Context  (contexto)  es  similar  a un  diccionario,  pero  un  Context  provee 
funcionalidades  adicionales,  como  se  cubre  en  el  capitulo  9. 

Los  nombres  de  las  variables  deben  comenzar  con  una  letra  (A-Z  o a-z)  y pueden 
contener  digitos,  guiones  bajos  y puntos.  (Los  puntos  son  un  caso  especial  al  que 
llegaremos  en  un  momento).  Los  nombres  de  variables  son  sensibles  a mayusculas- 
minusculas. 

Este  es  un  ejemplo  de  compilation  y renderizacion  de  una  plantilla,  usando  la 
plantilla  de  muestra  del  comienzo  de  este  capitulo: 

»>  from future import  print_fu notion 

»>  from  django. template  import  Template,  Context 
»>  raw_template  = <p>Estimado:  {{  nombre  }},</p> 

...  <p>Gracias  por  el  pedido  que  ordeno  de  {{  empresa }}.  El 
...  pedido  se  enviara  el  {{  ship_date|date:  "j  F Y"  }}.</p> 

...  {%  if  garantia  %} 

...  <p>La  garantia  sera  incluida  en  el  paquete.</p> 

...  {%  else  %} 

...  <p>Lamentablemente  no  ordeno  una  garantia,  por  lo  que  los 
...  danos  al  producto  corren  por  su  cuenta.</p> 

...  {%  endif  %} 

...  <p>Sinceramente  <br  />{{  empresa  }}</p> 

»>  t = Template(raw_template) 

>»  import  datetime 

»>  c = Context({'nombre':  'Juan  Perez', 

...  'empresa':  'Entrega  veloz', 

...  'fecha':  datetime. date(2014,  10, 10), 

...  'ordered_warranty':  False}) 

»>  t.render(c) 

u"<p>Estimado  Juan  Perez, </p>\n\n<p>Gracias  por  el  pedido  que  ordeno  de  Entrega 
veloz.  El  pedido  se  enviara  el  10  Octubre  2014.</p>\n\n\n<p>  Lamentablemente  no 
ordeno  una  garantia,  por  lo  que  los  danos\nal  producto  corren  por  su  cuenta.</p>\n\n\n 
<p>Sinceramente,<br  />Entrega  veloz</p>" 

Veamos  paso  a paso  este  codigo,  una  sentencia  a la  vez: 

■ Primero,  importamos  la  clase  Template  y Context,  ambas  se  encuentran  en  el 
modulo  django.template.  Guardamos  en  texto  crudo,  nuestra  plantilla  en  la 
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variable  raw_template.  Nota  que  usamos  triple  comillas  para  delimitar  la 
cadena  de  caracteres,  debido  a que  abarca  varias  lineas;  en  el  codigo  Python, 
las  cadenas  de  caracteres  delimitadas  con  una  sola  comilla  indican  que  no 
puede  abarcar  varias  lineas. 

■ Luego,  creamos  un  objeto  plantilla,  t,  pasandole  raw_template  al  constructor 
de  la  clase  Template. 

■ Importamos  el  modulo  datetime  desde  la  biblioteca  estandar  de  Python, 
porque  lo  vamos  a necesitar  en  la  proxima  sentencia. 

■ Entonces,  creamos  un  objeto  Context  , c.  El  constructor  de  Context  toma  un 
diccionario  de  Python,  el  cual  mapea  los  nombres  de  las  variables  con  los 
valores.  Aqui,  por  ejemplo,  especificamos  que  nombre  es  'Juan  Perez', 
empresa  es  'Entrega  Veloz',  y asi  sucesivamente. 

■ Finalmente,  llamamos  al  metodo  render!)  sobre  nuestro  objeto  de  plantilla, 
pasando  a este  el  contexto.  Este  retorna  la  plantilla  renderizada  - esto  es, 
reemplaza  las  variables  de  la  plantilla  con  los  valores  reales  de  las  variables,  y 
ejecuta  cualquier  bloque  de  etiquetas. 

Nota  que  el  parrafo  “Lamentablemente  no  ordeno  una  garantia”  fue  mostrado 
porque  la  variable  garantia  se  evalua  como  False.  Tambien  nota  que  la  fecha 
10  Octubre  2014,  es  mostrada  acorde  al  formato  de  cadena  de  caracteres  j F Y. 
(Explicaremos  los  formatos  de  cadenas  de  caracteres  para  el  filtro  date  a la 
brevedad). 

Si  eres  nuevo  en  Python,  quizas  te  preguntes  por  que  la  salida  incluye  los 
caracteres  de  nueva  linea  (' \n')  en  vez  de  mostrar  los  saltos  de  linea.  Esto 
sucede  porque  es  una  sutileza  del  interprete  interactive  de  Python:  la  llamada 
a t.render(c)  retorna  una  cadena  de  caracteres,  y el  interprete  interactive,  por 
omision,  muestra  una  representation  de  esta,  en  vez  de  imprimir  el  valor  de  la 
cadena.  Si  quieres  ver  la  cadena  de  caracteres  con  los  saltos  de  lineas  como 
verdaderos  saltos  de  lineas  en  vez  de  caracteres  '\n',  usa  la  sentencia  print: 
print  (t.render(c)). 

Estos  son  los  fundamentos  del  uso  del  sistema  de  plantillas  de  Django:  solo  escribe 
una  plantilla,  crea  un  objeto  Template,  crea  un  Context,  y llama  al  metodo  render!). 

Multiples  contextos,  mismas  plantillas 

Una  vez  que  tengas  un  objeto  Template,  puedes  renderizarlo  con  multiples 
contextos,  por  ejemplo: 

»>  from future import  print_fu notion 

»>  from  django. template  import  Template,  Context 
»>  t = Template('Hola,  {{  nombre  }}') 

»>  print  (t.render(Context({'nombre':  'Juan'}))) 

Hola,  Juan 

»>  print  (t.render(Context({'nombre':  'Julia'}))) 

Hola,  Julia 

»>  print  (t.render(Context({'nombre':  'Paty'}))) 

Hola,  Paty 
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Cuando  estes  usando  la  misma  plantilla  fuente  para  renderizar  multiples 
contextos  como  este,  es  mas  eficiente  crear  el  objeto  Template  una  sola  vezy  luego 
llamar  al  metodo  renderQ  sobre  este  muchas  veces: 


# Mai 

for  nombre  in  ('Juan',  'Julia',  'Paty'): 
t = Template('Hola,  {{  nombre  }}’) 

print  (t.render(Context({'nombre':  nombre}))) 

# Bien 

t = Template('Hola,  {{  nombre  }}') 
for  nombre  in  ('Juan',  'Julia',  'Paty'): 

print  (t.render(Context({'nombre':  nombre}))) 

El  analizador  sintactico  de  las  plantillas  de  Django  es  bastante  rapido.  Detras  de 
escena,  la  mayoria  de  los  analizadores  pasan  con  una  simple  llamada  a una  expresion 
regular  corta.  Esto  es  un  claro  contraste  con  el  motor  de  plantillas  de  XML,  que 
incurre  en  la  excesiva  actividad  de  un  analizador  XML,  y tiende  a ser  ordenes  de 
magnitud  mas  lento  que  el  motor  de  renderizado  de  Django. 

Busqueda  del  contexto  de  una  variable 

En  los  ejemplos  vistos  hasta  el  momento,  pasamos  valores  simples  a los  contextos  - 
en  su  mayoria  cadena  de  caracteres,  mas  un  datetime. date.  Sin  embargo,  el  sistema 
de  plantillas  maneja  elegantemente  estructuras  de  datos  mas  complicadas,  como 
listas,  diccionarios  y objetos  personalizados. 

La  clave  para  recorrer  estructuras  de  datos  complejos  en  las  plantillas  de  Django 
es  el  uso  del  caracter  pun  to  (.),  usa  un  punto  para  acceder  a las  claves  de  un 
diccionario,  atributos,  indices  o metodos  de  un  objeto. 

Esto  es  mejor  ilustrarlos  con  algunos  ejemplos.  Por  ejemplo,  imagina  que  pasas  un 
diccionario  de  Python  a una  plantilla.  Para  acceder  al  valor  de  ese  diccionario  por  su 
clave,  solo  usa  el  punto: 

»>  from  django. template  import  Template,  Context 
»>  persona  = {'nombre':  'Silvia',  'edad':  '43'} 

»>  t = Template('{{  persona.nombre  }}  tiene 
{{  persona. edad  }}  anos.') 

»>  c = Context({'persona':  persona}) 

»>  t.render(c) 
u'Silvia  tiene  43  anos.' 

De  forma  similar,  los  puntos  te  permiten  acceder  a los  atributos  de  los  objetos.  Por 
ejemplo,  un  objeto  de  Python  datetime. date  tiene  los  atributos  year,  month  y day  y 
puedes  usar  el  punto  para  acceder  a ellos  en  las  plantillas  de  Django: 

»>  from  django. template  import  Template,  Context 

»>  import  datetime 

»>  d = datetime. date(1993,  5,  2) 

»>  d.year 

1993 

»>  d. month 

5 
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»>  d.day 

2 

»>  t = Template('EI  mes  es  {{  date. month  }}  y el  ano 
es  {{ date. year }}.') 

»>  c = Context({'date':  d}) 

»>  t.render(c) 

u'EI  mes  es  5 y el  anos  es  1993.' 

Este  ejemplo  usa  una  clase  personalizada,  que  demuestra  que  la  variable  punto 
permite  acceder  a objetos  de  forma  arbitraria: 

»>  from  django. template  import  Template,  Context 
»>  class  Persona(objec ): 

...  def init ( ;lf,  nombre,  apellido): 

...  self.nombre,  self. apellido  = nombre,  apellido 
»>  t = Template('Hola,  {{  persona. nombre  }} 

{{ persona. apellido  }}.') 

»>  c = Context({'persona':  Persona('Juan',  'Perez')}) 

»>  t.render(c) 

u'Hola,  Juan  Perez.' 

Los  puntos  tambien  son  utilizados  para  llamar  a metodos  sobre  los  objetos.  Por 
ejemplo,  cada  cadena  de  caracteres  de  Python  posee  metodos  upper()  y isdigitO,  por 
lo  que  puedes  llamar  a estos  metodos  en  las  plantillas  de  Django  usando  la  misma 
sintaxis  de  punto: 

»>  from  django. template  import  Template,  Context 
»>  t = Template('{{  var }}  - {{  var. upper }}  - 
{{ var.isdigit }}') 

»>  t.render(Context({'var':  'hola'})) 

u'hola  --  HOLA  --  False' 

»>  t.render(Context({'var':  '123'})) 
u'123  - 123  - True' 


Observa  que  no  tienes  que  incluir  los  parentesis  en  las  llamadas  a los  metodos. 
Ademas,  tampoco  es  posible  pasar  argumentos  a los  metodos;  solo  puedes  llamar  a 
los  metodos  que  no  requieran  argumentos.  (Explicaremos  esta  filosofia,  mas  adelante 
en  este  capitulo). 

Finalmente,  los  puntos  tambien  son  usados  para  acceder  a los  indices  de  las  listas, 
por  ejemplo: 

»>  from  django. template  import  Template,  Context 
»>  t = Template('Fruta  2 es  {{ frutas.2  }}.') 

»>  c = Context({'frutas':  [ manzana’,  'platano',  'pera']}) 

»>  t.render(c) 

u'Fruta  2 es  pera.' 

Los  indices  negativos  de  las  listas  no  estan  permitidos.  Por  ejemplo,  la  variable 
{{frutas.  -1 }}  causara  una  Temp lateSyntaxError. 


LISTAS  EN  PYTHON 


Las  listas  de  Python  comienzan  en  cero,  entonces  el  primer  elemento  es  el  0,  el 
segundo  es  el  1 y asi  sucesivamente. 
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La  busqueda  del  punto  puede  resumirse  a esto:  cuando  el  sistema  de  plantillas 
encuentra  un  punto  en  una  variable,  intentara  buscar  en  este  orden: 

1.  Diccionario  (por  ej.  foo["bar"]) 

2.  Atributo  (por  ej.  foo.bar) 

3.  Llamada  de  metodo  (por  ej.  foo.bar(j) 

4.  Indice  de  lista  (por  ej.  foojbar]) 

El  sistema  utiliza  el  primer  tipo  de  busqueda  que  funcione.  Es  la  logica  de 
cortocircuito. 

Los  puntos  pueden  ser  anidados  a multiples  niveles  de  profundidad.  El  siguiente 
ejemplo  usa  {{  persona.name.upper  }},  el  que  se  traduce  en  una  busqueda  de 
diccionario  (personafnombre'])  y luego  en  una  llamada  a un  metodo  (upper(j): 

»>  from  django. template  import  Template,  Context 
»>  persona  = {'nombre':  'Silvia',  'edad':  '43'} 

»>  t = Template('{{  persona.nombre. upper }}  tiene 
{{  person. age  }}  anos.') 

»>  c = Context({'persona':  persona}) 

»>  t.render(c) 
u'SILVIA  tiene  43  anos.’ 


Comportamiento  de  la  llamada  a los  metodos 

La  llamada  a los  metodos  es  ligeramente  mas  compleja  que  los  otros  tipos  de 
busqueda.  Aqui  hay  algunas  cosas  a tener  en  cuenta: 

■ Si,  durante  la  busqueda  de  metodo,  un  metodo  provoca  una  excepcion,  la 
exception  sera  propagada,  a menos  que  la  excepcion  tenga  un  atributo 
silent_variable_failure  cuyo  valor  sea  True. 

■ Si  la  excepcion  contiene  el  atributo  silent_variable_failure,  la  variable  sera 
renderizada  como  un  string  vacio,  por  ejemplo: 

»>  t = Template("Mi  nombre  es  {{  persona.nombre }}.") 

»>  class  ClasePersona: 

...  def  nombre(self): 

...  raise  AssertionError,  "too" 

»>  p = ClasePersona() 

>»  t.render(Context({"persona":  p})) 

Traceback  (most  recent  call  last): 

AssertionError:  too 

>»  class  SilentAssertionError(AssertionError): 

...  silent_variable_failure  = True 
>»  class  ClasePersona2: 

...  def  nombre(self): 

...  raise  SilentAssertionError 
»>  p = ClasePersona2() 

»>  t.render(Context({"persona":  p})) 
u'Mi  nombre  es  .' 
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■ La  llamada  a un  metodo  funcionara  solo  si  el  metodo  no  requiere  argumentos. 
En  otro  caso,  el  sistema  pasara  a la  siguiente  busqueda  de  tipo  indice  de  lista. 

■ Evidentemente,  algunos  metodos  tienen  efectos  secundarios,  por  lo  que  seria 
absurdo,  en  el  mejor  de  los  casos,  y posiblemente  un  agujero  de  seguridad, 
permitir  que  el  sistema  de  plantillas  tenga  acceso  a ellos. 

Digamos,  por  ejemplo,  que  tienes  un  objeto  CuentaBanco  que  tiene  un 
metodo  borrar().  Lina  plantilla  no  deberia  permitir  incluir  algo  como  {{ 
cuenta.borrar  }},  donde  cuenta  es  un  objeto  CuentaBanco,  jya  que  el  objeto 
sera  borrado  cuando  se  renderice  la  plantilla! 

Para  prevenir  esto,  asigna  el  atributo  alters_data  de  la  funcion  en  el  metodo: 
def  delete(self): 

# Borra  una  cuenta 

delete. alters_data  = True 

El  sistema  de  plantillas  no  deberia  ejecutar  cualquier  metodo  marcado  de  esta 
forma.  En  otras  palabras,  si  una  plantilla  incluye  {{  cuenta.borrar}}  y el  metodo 
borrarO,  marcado  como  alters_data=True,  esta  etiqueta  no  ejecutara  el  metodo 
delete 0-  Ya  que  este  fallara  silenciosamente. 


QUE  ES  SELF? 


Self  es  simplemente  el  nombre  convencional  para  el  primer  argumento  de  un  metodo 
en  Python. 

Por  ejemplo,  un  metodo  definido  de  la  forma  methjself,  a,  b,  c)  debe  ser  llamado 
con  x.meth(a,  b,  c),  por  alguna  instancia  de  la  clase  x,  en  la  cual  ocurre  la  definition; 
de  esta  forma  el  metodo  llamado  pensara  que  es  llamado  como  meth(x,  a,  b,  c). 

iComo  se  manejan  las  variables  invalidas? 

De  forma  predeterminada,  si  una  variable  no  existe,  el  sistema  de  plantillas  renderiza 
esta  como  una  cadena  vacia,  fallando  silenciosamente,  por  ejemplo: 

»>  from  django. template  import  Template,  Context 
»>  t = Template('Tu  nombre  es  {{  nombre  }}.') 

»>  t.render(Context()) 

u'Tu  nombre  es  .' 

»>  t.render(Context({'var':  'hola'})) 

u'Tu  nombre  es  .' 

»>  t.render(Context({'NOMBRE':  'hola'})) 

u'Tu  nombre  es  .' 

»>  t.render(Context({'Nombre':  'hola'})) 

u’Tu  nombre  es  ." 

El  sistema  falla  silenciosamente  en  vez  de  levantar  una  exception  porque  intenta 
ser  flexible  a los  errores  humanos.  En  este  caso,  todas  las  busquedas  fallan  porque  los 
nombres  de  las  variables,  o su  capitalization  es  incorrecta.  En  el  mundo  real,  es 
inaceptable  para  un  sitio  web  ser  inaccesible  debido  a un  error  de  sintaxis  tan 
pequeno. 


Jugando  con  objetos  Context 
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La  mayorfa  de  las  veces,  solo  tendras  que  instanciar  un  objeto  Context  pasandole  un 
diccionario,  completamente  poblado  a Context.  Sin  embargo,  tambien  puedes 
agregar  y quitar  elementos  de  un  objeto  Context  una  vez  que  este  esta  instanciado, 
usando  la  sintaxis  estandar  de  los  diccionarios  de  Python: 


»>  from  django. template  import  Context 
»>  c = Context({"foo":  "bar"}) 

»>  c['foo'] 

'bar' 

»>  del  c['foo'] 

»>  c['foo'] 

Traceback  (most  recent  call  last): 
KeyError:  'too' 

»>  c['nuevavariable']  = 'hola' 

»>  c['nuevavariable'] 

'hola' 


Etiquetas  basicas  de  plantillas  y filtros 

Como  hemos  mencionamos  anteriormente,  el  sistema  de  plantillas  se  distribuye  con 
etiquetas  y filtros  incorporados.  Las  secciones  que  siguen  proveen  un  resumen  de  la 
mayoria  de  las  etiquetas  y filtros. 

Etiquetas 

if/else 

La  etiqueta  {%  if  %}  evalua  una  variable,  y si  esta  es  “true”  (esto  es,  existe,  no  esta 
vacia  y no  es  un  valor  Boolean  falso),  el  sistema  mostrara  todo  lo  que  hay  entre  {%  if 
%}  y {%  endif  %},  por  ejemplo: 

{%  if  es_fin_de_semana  %} 

<p>jBienvenido  fin  de  semana!</p> 

{%  endif  %} 

La  etiqueta  {%  else  %}  es  opcional: 

{%  if  es_fin_de_semana  %} 

<p>iBienvenido  fin  de  semana!</p> 

{%  else  %} 

<p>De  vuelta  al  trabajo.</p> 

{%  endif  %} 


LAS  “VERDADES”  EN  PYTHON 


En  Python  y en  el  sistema  de  plantillas  de  Django,  los  siguientes  objetos  son 
evaluados  como  False  (falsos)  en  un  contexto  booleano: 

■ Lina  lista  vacia  ([]), 

■ Una  tupla  vacia  ( () ) , 

■ Un  diccionario  vacio  ({}), 
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■ Unacadenavacia  ("), 

■ Elcero(O), 

■ El  objeto  especial  None 

■ El  objeto  False  (obviamente) 

■ Objetos  personalizados  que  definen  su  propio  comportamiento  en  un  contexto 
boleano  (Es  la  ventaja  de  usar  Python) 

■ Todo  lo  demas  es  evaluado  como  verdadero  (True). 

None:  es  un  valor  especial  de  Python  que  devuelven  funciones  que  o bien  no 
tienen  sentencia  de  return  o bien  tienen  una  sentencia  de  return  sin  argumento. 

La  etiqueta  {%  if  %}  acepta  and,  or,  o not  para  testear  multiples  variables,  o para 
negarlas, 
por  ejemplo: 

{%  if  lista_atletas  and  lista_entrenadores  %} 

Atletas  y Entrenadores  estan  disponibles 
{%  endif  %} 

{%  if  not  lista_atletas  %} 

No  hay  atletas 
{%  endif  %} 

{%  if  lista_atletas  or  lista_entrenadores  %} 

Hay  algunos  atleta  o algunos  entrenadores 

{%  endif  %} 

{%  if  not  lista_atletas  or  lista_entrenadores  %} 

No  hay  atletas  o no  hay  entrenadores. 

{%  endif  %} 

{%  if  lista_atletas  and  not  lista_entrenadores  %} 

Hay  algunos  atletas  y absolutamente  ningun  entrenador. 

{%  endif  %} 

Las  etiquetas  {%  if  %}  no  permiten  las  clausulas  and  y or  en  la  misma  etiqueta, 
porque  el  orden  de  evaluation  logico  puede  ser  ambiguo.  Por  ejemplo,  esto  es 
invalido: 

{%  if  lista_atletas  and  lista_entrenadores  or  lista_porristas  %} 

No  se  admite  el  uso  de  parentesis  para  controlar  el  orden  de  las  operaciones.  Si 
necesitas  parentesis,  considera  efectuar  la  logica  en  el  codigo  de  la  vista  para 
simplificar  las  plantillas. 

Aun  asi,  si  necesitas  combinar  and  y or  para  hacer  logica  avanzada,  usa  etiquetas 
{%  if  %}  anidadas,  por  ejemplo: 

{%  if  lista_atletas  %} 

{%  if  lista_entrenadores  or  lista_porristas  %} 
jTenemos  atletas  y entrenadores  o porristas! 

{%  endif  %} 

{%  endif  %} 

Usar  varias  veces  el  mismo  operador  logico  esta  bien,  pero  no  puedes  combinar 
diferentes  operadores.  Por  ejemplo,  esto  es  valido: 
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{%  if  lista_atletas  or  lista_entrenadores  or  lista_padres  or  lista_maestros  %} 

No  hay  una  etiqueta  {%  elif  %}.  En  su  lugar  usa  varias  etiquetas  {%  if  %}  anidadas 
para  conseguir  el  mismo  resultado: 

{%  if  lista_atletas  %} 

<p>Aquf  estan  los  atletas:  lista_atletas  }}.</p> 

{%  else  %} 

<p>No  hay  atletas  disponibles.</p> 

{%  if  lista_entrenadores  %} 

<p>Aquf  estan  los  entrenadores:  { lista_entrenadores  }}.</p> 

{%  end  if  %} 

{%  end  if  %} 

Asegurate  de  cerrar  cada  {%  if  %}  con  un  {%  endif  %}.  En  otro  caso,  Django 
levantara  la  exception  TemplateSyntaxError. 

For 

La  etiqueta  {%  for  %}  permite  iterar  sobre  cada  uno  de  los  elementos  de  una 
secuencia.  Como  en  la  sentencia  for  de  Python,  la  sintaxis  es  for  X in  Y,  donde  Y es  la 
secuencia  sobre  la  que  se  hace  el  bucle  y X es  el  nombre  de  la  variable  que  se  usara 
para  cada  uno  de  los  ciclos  del  bucle. 

Cada  vez  que  atravesamos  el  bucle,  el  sistema  de  plantillas  renderizara  todo  entre 
{%  for  %}  y {%  endfor  %}. 

Por  ejemplo,  puedes  usar  lo  siguiente  para  mostrar  una  lista  de  atletas  tomadas  de 
la  variable  lista_atletas: 

<ul> 

{%  for  atleta  in  lista_atletas  %} 

<li>{{  atleta.nombre  }}</li> 

{%  endfor  %} 

</ul> 

Agrega  reversed  a la  etiqueta  para  iterar  sobre  la  lista  en  orden  inverso: 

{%  for  atleta  in  lista_atletas  reversed  %} 

{%  endfor  %} 

Es  posible  anidar  etiquetas  {%  for  %}: 

{%  for  pais  in  paises  %} 

<hl>{{  pais. nombre  }}</hl> 

<ul> 

{%  for  ciudad  in  pais.lista_ciudades  %} 

<li>{{  ciudad  }}</li> 

{%  endfor  %} 

</ul> 

{%  endfor  %} 

Un  uso  muy  comun  de  la  etiqueta  for,  es  para  comprobar  el  tamano  de  una  lista 
antes  de  iterar  sobre  ella  y mostrar  algun  texto  en  especial,  si  la  lista  esta  vacia.: 
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{%  if  lista_atletas  %} 

{%  for  atleta  in  lista_atletas  %} 

<p>{{  atleta. nombre  }}</p> 

{%  endfor  %} 

{%  else  %} 

<p>No  hay  atletas.  Unicamente  programadores.</p> 

{%  endif  %} 

El  ejemplo  anterior  es  tan  comun,  que  la  etiqueta  for  soporta  una  clausula 
opcional: 

{%  empty  %}  que  te  permite  definir  lo  que  hay  que  hacer  si  la  lista  esta  vacia.  El 
siguiente  ejemplo  es  equivalente  al  anterior: 

{%  for  atleta  in  lista_atletas  %} 

<p>{{  athlete. nombre  }}</p> 

{%  empty  %} 

<p>No  hay  atletas.  Unicamente  programadores.</p> 

{%  endfor  %} 

No  se  admite  la  “ruptura”  de  un  bucle  antes  de  que  termine.  Si  quieres  conseguir 
esto,  cambia  la  variable  sobre  la  que  estas  iterando  para  que  incluya  solo  los  valores 
sobre  los  cuales  quieres  iterar.  De  manera  similar,  no  hay  apoyo  para  la  sentencia 
“continue”  que  se  encargue  de  retornar  inmediatamente  al  inicio  del  bucle. 
(Consulta  la  section  “Filosofia  y limitaciones”  mas  adelante  para  comprender  el 
razonamiento  detras  de  esta  decision  de  diseno.) 

Dentro  de  cada  bucle,  la  etiqueta  {%  for  %}  permite  acceder  a una  variable  llamada 
forloop,  dentro  de  la  plantilla.  Esta  variable  tiene  algunos  atributos  que  toman 
information  acerca  del  progreso  del  bucle: 

■ forloop. counter  es  siempre  asignada  a un  numero  entero  representando  el 
numero  de  veces  que  se  ha  entrado  en  el  bucle.  Esta  es  indexada  a partir  de  1, 
por  lo  que  la  primera  vez  que  se  ingresa  al  bucle,  forloop. counter  sera  1.  Aqui 
un  ejemplo: 

{%  for  objeto  in  lista  %} 

<p>{{  forloop. counter }}:  {{ objeto  }}</p> 

{%  endfor  %} 

■ forloop. counterO  es  como  forloop. counter,  excepto  que  esta  es  indexada  a partir 
de  cero.  Contendra  el  valor  0 la  primera  vez  que  se  atraviese  el  bucle. 

■ forloop. revcounter  es  siempre  asignado  a un  entero  que  representa  el  numero 
de  iteraciones  que  faltan  para  terminar  el  bucle.  La  primera  vez  que  se  ejecuta 
el  bucle  forloop. revcounter  sera  igual  al  numero  de  elementos  que  hay  en  la 
secuencia.  La  ultima  vez  que  se  atraviese  el  bucle,  a forloop. revcounter  se  la 
asignara  el  valor  1. 

■ forloop. revcounterO  es  como  forloop. revcounter,  a exception  de  que  esta 
indexada  a partir  de  cero.  La  primera  vez  que  se  atraviesa  el  bucle, 
forloop.revcounterO  es  asignada  al  numero  de  elementos  que  hay  en  la 
secuencia  menos  1.  La  ultima  vez  que  se  atraviese  el  bucle,  el  valor  de  esta 
sera  0. 
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■ forloop. first  es  un  valor  booleano  asignado  a True  si  es  la  primera  vez  que  se 
pasa  por  el  bucle.  Esto  es  conveniente  para  ocasiones  especiales: 


{%  for  objeto  in  objetos  %} 

{%  if  forloop. first  %}<li  class="first">{%  else  %}<li>{%  endif  %} 
{{ objeto  }}  </li> 

{%  endfor  %} 


■ forloop. last  es  un  valor  booleano  asignado  a True  si  es  la  ultima  pasada  por  el 
bucle.  Un  uso  comun  es  para  esto  es  poner  un  caracter  pipe  entre  una  lista  de 
enlaces: 

{%  for  enlace  in  enlaces  %}  {{  enlace  }}  {%  if  not  forloop. last  %}  | {%  endif  %} 

{%  endfor  %} 

El  codigo  de  la  plantilla  de  arriba  puede  mostrar  algo  parecido  a esto: 

Enlacel  | Enlace2  | Enlace3  | Enlace4 

Tambien  se  usa  comunmente,  para  poner  comas  entre  palabras  de  una  lista: 
por  ejemplo  para  mostrar  una  lista  de  lugares  favoritos: 

{%  for  p in  lugares  %}{{  p }}{%  if  not  forloop. last  %}, 

{%  endif  %}{%  endfor  %} 

■ forloop. parentloop  hace  referencia  al  objeto  padre  de  forloop,  en  el  caso  de 
bucles  anidados.  Aqui  un  ejemplo: 

{%  for  pais  in  paises  %} 

<table> 

{%  for  ciudad  in  pais.lista_ciudades  %} 

<tr> 

<td>pais  #{{  forloop. parentloop. counter  }}</td> 

<td>City  #{{  forloop. counter  }}</td> 

<td>{{  ciudad  }}</td> 

</tr> 

{%  endfor  %} 

</table> 

{%  endfor  %} 

La  variable  magica  forloop  esta  unicamente  disponible  dentro  del  bucle.  Despues 
de  que  el  analizados  sintactico  encuentra  {%  endfor  %},  forloop  desaparece. 


CONTEXTOS  Y LA  VARIABLE  FORLOOP 


Dentro  de  un  bloque  {%  for  %},  las  variables  existentes  se  mueven  fuera  del  bloque  a 
fin  de  evitar  sobrescribir  la  variable  magica  forloop.  Django  expone  este  contexto 
moviendo  forloop. parentloop.  Generalmente  no  necesitas  preocuparte  por  esto,  si 
provees  una  variable  a la  plantilla  llamada  forloop  (a  pesar  de  que  no  lo 
recomendamos),  se  llamara  forloop. parentloop  mientras  este  dentro  del  bloque  {%  for 
%}. 


ifequal/ifnotequal 
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El  sistema  de  plantillas  de  Django  a proposito  no  es  un  lenguaje  de  programacion 
completo  y por  lo  tanto  no  permite  ejecutar  sentencias  arbitrarias  de  Python.  (Mas 
sobre  esta  idea  en  la  seccion  “Filosofia  y limitaciones”)-  Sin  embargo,  es  bastante 
comun  que  una  plantilla  requiera  comparar  dos  valores  y mostrar  algo  si  ellos  son 
iguales  - Django  provee  la  etiqueta 
{%  ifequal  %}  para  este  proposito. 

La  etiqueta  {%  ifequal  %}  compara  dos  valores  y muestra  todo  lo  que  se  encuentra 
entre  {%  ifequal  %}  y {%  endifequal  %}  si  el  valor  es  igual. 

Este  ejemplo  compara  las  variables  usuario  y actual_usuario  de  la  plantilla: 

{%  ifequal  usuario  actual_usuario  %} 

<hl>jBienvenido!</hl> 

{%  endifequal  %} 

Los  argumentos  pueden  ser  strings  “hard-codeados”,  con  comillas  simples  o 
dobles,  por  lo  que  lo  siguiente  es  valido: 

{%  ifequal  seccion  'noticias'  %} 

<hl>Noticias</hl> 

{%  endifequal  %} 

{%  ifequal  seccion  "comunidad"  %} 

<hl>Comunidad</hl> 

{%  endifequal  %} 

Tal  como  {%  if  %},  la  etiqueta  {%  ifequal  %}  admite  opcionalmente  la  etiqueta 
{%  else  %}: 

{%  ifequal  seccion  'noticias'  %} 

<hl>Noticias</hl> 

{%  else  %} 

<hl>No  hay  noticias  nuevas</hl> 

{%  endifequal  %} 

En  las  variables  de  plantilla,  unicamente  las  cadenas  de  texto,  enteros  y los 
numeros  decimales  son  permitidos  como  argumentos  para  {%  ifequal  %}.  Estos  son 
ejemplos  validos: 

{%  ifequal  variable  1 %} 

{%  ifequal  variable  1.23  %} 

{%  ifequal  variable  'foo'  %} 

{%  ifequal  variable  "foo"  %} 

Cualquier  otro  tipo  de  variables,  tales  como  diccionarios  de  Python,  listas,  o 
booleanos,  no  pueden  ser  comparadas  con  {%  ifequal  %}.  Estos  ejemplos  son 
invalidos: 

{%  ifequal  variable  True  %} 

{%  ifequal  variable  [1,  2,  3]  %} 

{%  ifequal  variable  {'key':  'value'}  %} 

Si  necesitas  comprobar  cuando  algo  es  verdadero  o falso,  usa  la  etiqueta  {%  if  %}  en 
lugar  de  {%  ifequal  %}. 
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Comentarios 

A1  igual  que  en  HTML  o en  un  lenguaje  de  programacion  como  Python,  el  lenguaje  de 
plantillas  de  Django  permite  usar  comentarios.  Para  designar  un  comentario,  usa  {# 
#}: 

{#  Esto  es  un  comentario  #} 

Este  comentario  no  sera  mostrado  cuando  la  plantilla  sea  renderizada. 

Un  comentario  no  puede  abarcar  multiples  lineas.  Esta  limitation  mejora  la 
performance  del  analizador  sintactico  de  plantillas.  En  la  siguiente  plantilla,  la  salida 
del  renderizado  mostraria  exactamente  lo  mismo  que  la  plantilla  (esto  es,  la  etiqueta 
comentario  no  sera  tomada  como  comentario): 

Esto  es  una  {#  Esto  no  es 
un  comentario  #} 

prueba. 

Si  quieres  usar  un  comentario  que  abarque  varias  lineas,  usa  la  etiqueta  {% 
comment  %},  asi: 

{%  comment  %} 

Este  es  un  comentario 
que  abarca  varias  lineas 
{%  endcomment  %} 

Filtros 

Como  explicamos  anteriormente  en  este  capitulo,  los  filtros  de  plantillas  son  formas 
simples  de  alterar  el  valor  de  una  variable  antes  de  mostraria.  Los  filtros  se  parecen  a 
esto: 

{{  nonmbre|lower }} 

Esto  muestra  el  valor  de  {{  no  mb  re  }}  despues  de  aplicarle  el  filtro  lower,  el  cual 
convierte  el  texto  a minuscula.  Usa  una  pipe  o tuberia  (|)  para  aplicar  el  filtro. 

Los  filtros  pueden  ser  encadenados  - esto  quiere  decir  que,  la  salida  de  uno  de  los 
filtros  puede  ser  aplicada  al  proximo-.  Aqui  un  ejemplo  que  toma  el  primer  elemento 
de  una  lista  y la  convierte  a mayusculas: 

{{  mi_lista|first|upper }} 

Algunos  filtros  toman  argumentos.  Un  filtro  con  argumentos  se  ve  de  este  modo: 

{{  bio|truncatewords:"30" }} 

Esto  muestra  las  primeras  30  palabras  de  la  variable  bio.  Los  argumentos  de  los 
filtros  estan  siempre  entre  comillas  dobles. 

Los  siguientes  son  algunos  de  los  filtros  mas  importantes;  el  Apendice  E cubre  el 
resto. 


■ addslashes:  Agrega  una  contra-barra  antes  de  cualquier  contra-barra,  comilla 
simple  o comilla  doble.  Esto  es  util  si  el  texto  producido  esta  incluido  en  un 
string  de  JavaScript. 
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■ date:  Formatea  un  objeto  date  o datetime  de  acuerdo  al  formato  tornado 
como  parametro,  por  ejemplo: 

{{ fecha|date:"F  j,  Y" }} 

El  formato  de  los  strings  esta  deflnido  en  el  Apendice  E. 

■ escape:  Escapa  ampersands (&),  comillas,  y corchetes  del  string  tornado.  Esto 
es  usado  para  desinfectar  datos  suministrados  por  el  usuario  y asegurar  que 
los  datos  son  validos  para  XML  y XE1TML.  Especificamente,  escape  hace  estas 
conversiones: 

• Convierte  & en  &amp; 

• Convierte  < en  &lt; 

• Convierte  > en  &gt; 

• Convierte  " (comilla  doble)  en  &quot; 

• Convierte  ' (comilla  simple)  en  &#39; 

■ length:  Retorna  la  longitud  del  valor.  Puedes  usar  este  con  una  lista  o con  un 

string,  o con  cualquier  objeto  Python  que  sepa  como  determinar  su  longitud 
(o  sea  cualquier  objeto  que  tenga  el  metodo len ())• 

Filosoffa  y Limitaciones 

Ahora  que  tienes  una  idea  del  lenguaje  de  plantillas  de  Django,  debemos  senalar 
algunas  de  sus  limitaciones  intencionales,  junto  con  algunas  filosofias  detras  de  la 
forma  en  que  este  funciona. 

Mas  que  cualquier  otro  componente  de  la  aplicacion  web,  las  opiniones  de  los 
programadores  sobre  el  sistema  de  plantillas  varia  extremadamente.  El  hecho  de  que 
Python  solo  implemente  decenas,  sino  cientos,  de  lenguajes  de  plantillas  de  codigo 
abierto  lo  dice  todo.  Cada  uno  fue  creado  probablemente  porque  su  desarrollador 
estima  que  todos  los  existentes  son  inadecuados.  (jDe  hecho,  se  dice  que  es  un  rito 
para  los  desarrolladores  de  Python  escribir  su  propio  lenguaje  de  plantillas!  Si  todavia 
no  lo  has  hecho,  tenlo  en  cuenta.  Es  un  ejercicio  divertido). 

Con  eso  en  la  cabeza,  debes  estar  interesado  en  saber  que  Django  no  requiere  que 
uses  su  lenguaje  de  plantillas.  Pero  Django  pretende  ser  un  completo  framework  que 
provee  todas  las  piezas  necesarias  para  que  el  desarrollo  web  sea  productivo,  quizas  a 
veces  es  mas  conveniente  usar  el  sistema  de  plantillas  de  Django  que  otras 
bibliotecas  de  plantillas  de  Python,  pero  no  es  un  requerimiento  estricto  en  ningun 
sentido.  Como  veras  en  la  proxima  seccion  “Uso  de  plantillas  en  las  vistas”,  es  muy 
facil  usar  otro  lenguaje  de  plantillas  con  Django. 

Aun  asi,  es  claro  que  tenemos  una  fuerte  preferencia  por  el  sistema  de  plantillas  de 
Django.  El  sistema  de  plantillas  tiene  raices  en  la  forma  en  que  el  desarrollo  web  se 
realiza  en  World  Online  y la  experiencia  combinada  de  los  creadores  de  Django.  Estas 
son  algunas  de  esas  filosofias: 

■ La  logica  de  negocios  debe  ser  separada  de  la  presentacion  logicas  Vemos  al 
sistema  de  plantillas  como  una  herramienta  que  controla  la  presentacion  y la 
logica  relacionado  a esta  - y eso  es  todo.  El  sistema  de  plantillas  no  deberia 
admitir  funcionalidad  que  vaya  mas  alia  de  este  concepto  basico. 

Por  esta  razon,  es  imposible  llamar  a codigo  Python  directamente  dentro  de 
las  plantillas  de  Django.  Todo  “programador”  esta  fundamentalmente 
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limitado  al  alcance  de  lo  que  una  etiqueta  puede  hacer.  Es  posible  escribir 
etiquetas  personalizadas  que  hagan  cosas  arbitrarias,  pero  las  etiquetas  de 
Django  intencionalmente  no  permiten  ejecutar  codigo  arbitrario  de  Python. 

■ La  sintaxis  debe  ser  independiente  de  HTML/XML.  Aunque  el  sistema  de 
plantillas  de  Django  es  usado  principalmente  para  producir  HTML,  este 
pretende  ser  util  para  formatos  no  HTML,  como  texto  piano.  Algunos  otros 
lenguajes  de  plantillas  estan  basados  en  XML,  poniendo  toda  la  logica  de 
plantilla  con  etiquetas  XML  o atributos,  pero  Django  evita  deliberadamente 
esta  limitacion.  Requerir  un  XML  valido  para  escribir  plantillas  introduce  un 
mundo  de  errores  humanos  y mensajes  dificil  de  entender,  y usando  un  motor 
de  XML  para  parsear  plantillas  implica  un  inaceptable  nivel  de  overhead  en  el 
procesamiento  de  la  plantilla. 

■ Los  disenadores  se  supone  que  se  sienten  mas  comodos  con  el  codigo 
HTML.  El  sistema  de  plantillas  no  esta  disenado  para  que  las  plantillas 
necesariamente  sean  mostradas  de  forma  agradable  en  los  editores  WYSIWYG 
tales  como  Dreamweaver.  Eso  es  tambien  una  limitacion  severa  y no 
permitiria  que  la  sintaxis  sea  tan  clara  como  lo  es.  Django  espera  las  plantillas 
de  los  autores  para  estar  comodo  editando  HTML  directamente. 

■ Se  supone  que  los  disenadores  no  son  programadores  Python.  El  sistema 
de  plantillas  de  los  autores  reconoce  que  las  plantillas  de  las  paginas  web  son 
en  la  mayoria  de  los  casos  escritos  por  disenadores,  no  por  programadores,  y 
por  esto  no  deberia  asumir  ningun  conocimiento  de  Python. 

Sin  embargo,  el  sistema  tambien  pretende  acomodar  pequenos  grupos  en  los 
cuales  las  plantillas  sean  creadas  por  programadores  de  Python.  Esto  ofrece 
otro  camino  para  extender  la  sintaxis  del  sistema  escribiendo  codigo  Python 
puro.  (Mas  de  esto  en  el  capitulo  9). 

■ No  se  pretende  inventar  un  lenguaje  de  programacion.  El  objetivo  es 
ofrecer  solo  la  suficiente  funcionalidad  de  programacion,  tales  como 
ramification  e iteration,  que  son  esenciales  para  hacer  presentaciones 
relacionadas  a decisiones. 

Como  resultado  de  esta  filosofia,  el  lenguaje  de  plantillas  de  Django  tiene  las 
siguientes  limitaciones: 

■ Una  plantilla  no  puede  asignar  una  variable  o cambiar  el  valor  de  esta.  Esto  es 
posible  escribiendo  una  etiqueta  personalizada  para  cumplir  con  esta  meta 
(ve  el  capitulo  10),  pero  la  pila  de  etiquetas  de  Django  no  lo  permite. 

■ Una  plantilla  no  puede  llamar  codigo  Python  crudo.  No  hay  forma  de  ingresar 
en  “modo  Python”  o usar  sentencias  puras  de  Python.  De  nuevo,  esto  es 
posible  creando  plantillas  personalizadas,  pero  la  pila  de  etiquetas  de  Django 
no  lo  permite. 

Usando  el  sistema  de  plantillas  en  las  vistas 

Has  aprendido  el  uso  basico  del  sistema  de  plantillas;  ahora  vamos  a usar  este 
conocimiento  para  crear  una  vista.  Recordemos  la  vista  fecha_actual  en 
misitio .views,  la  que  comenzamos  en  el  capitulo  anterior.  Se  vela  como  esta: 
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from  django.http  import  HttpResponse 
import  datetime 

def  fecha_actual(request): 

ahora=  datetime. datetime. now() 

html  = "<html><body>Hoy  es:  %s.</body></html>"  % ahora 
return  HttpResponse(html) 

Vamos  a cambiar  esta  vista  usando  el  sistema  de  plantillas  de  Django.  Primero, 
podemos  pensar  en  algo  como  esto: 

import  datetime 

from  django. template  import  Template,  Context 
from  django.http  import  HttpResponse 

def  fecha_actual(request): 
ahora  = datetime. datetime. now() 

t = Template("<html><body>Hoy  es  {{ fecha_actual  }}.</bodyx/html>") 
html  = t.render(Context({'fecha_actual':  ahora})) 
return  HttpResponse(html) 

Seguro,  esta  vista  usa  el  sistema  de  plantillas,  pero  no  soluciona  el  problema  que 
planteamos  en  la  introduction  de  este  capitulo.  A saber,  la  plantilla  sigue  estando 
incrustada  en  el  codigo  Python.  Vamos  a solucionar  esto  poniendo  la  plantilla  en  un 
archivo  separado,  que  la  vista  cargara  automaticamente. 

Puedes  considerar  primero  guardar  la  plantilla  en  algun  lugar  del  disco  y usar  las 
funcionalidades  de  Python  para  abrir  y leer  el  contenido  de  la  plantilla.  Esto  puede 
verse  asi,  suponiendo  que  la  plantilla  este  guardada  en 
/ home  / dj  angouser  / templates  / miplantilla.html: 

import  datetime 

from  django. template  import  Template,  Context 
from  django.http  import  HttpResponse 

def  fecha_actual(request): 

ahora  = datetime. datetime. now() 

# Manera  simple  de  usar  plantillas  del  sistema  de  archivos. 

# Esto  es  malo,  porque  no  toma  en  cuenta  los  archivos  no  encontrados. 
fp  = ;pen(7home/djangouser/templates/miplantilla.htmr) 

t = Template(fp.read()) 
fp.close() 

html  = t.render(Context({'fecha_actual':  ahora})) 
return  HttpResponse(html) 


Esta  aproximacion,  sin  embargo,  es  poco  elegante  por  estas  razones: 

■ No  maneja  el  caso  en  que  no  encuentre  el  archivo.  Si  el  archivo 
mytemplate.html  no  existe  o no  es  accesible  para  lectura,  la  llamada  a open() 
levantara  la  exception  IOError. 
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■ Involucra  la  ruta  de  tu  plantilla.  Si  vas  a usar  esta  tecnica  para  cada  una  de  las 
funciones  de  las  vistas,  estaras  duplicando  rutas  de  plantillas.  jSin  mencionar 
que  esto  implica  teclear  mucho  mas! 

■ Incluye  una  cantidad  aburrida  de  codigo  repetitive).  Tienes  mejores  cosas  para 
hacer  en  vez  de  escribir  open(),  fp.readO  y fp.closeO  cada  vez  que  cargas  una 
plantilla 

Para  solucionar  estos  problemas,  usamos  cargadores  de  plantillas  y directorios  de 
plantillas,  los  cuales  son  descritos,  en  las  siguientes  secciones. 

Cargadores  de  plantillas 

Django  provee  una  practica  y poderosa  API  para  cargar  plantillas  del  disco,  con  el 
objetivo  de  quitar  la  redundancia  en  la  carga  de  la  plantilla  y en  las  mismas  plantillas. 

Para  usar  la  API  para  cargar  plantillas,  primero  necesitas  indicarle  al  framework 
donde  estan  guardadas  tus  plantillas.  El  lugar  para  hacer  esto  es  en  el  archivo  de 
configuracidn,  que  mencionamos  en  el  capitulo  anterior,  cuando  introducimos  los 
ajuste  en  ROOT_URLCONF  (El  archivo  de  configuracidn  de  Django  es  el  lugar  para 
poner  configuraciones  para  tu  instancia  de  Django). 

Si  estas  siguiendonos  abre  tu  archivo  settings.py  y agrega  la  variable 
TEMPLATE_DIRS: 

TEMPLATE_DIRS  = ( 

# Pon  cadenas  del  tipo  "/home/html/django_templates"  o 

# En  Windows  usa  "C:/www/django/templates". 

) 


Estas  configuraciones  le  indican  al  mecanismo  de  carga  de  plantillas  donde  buscar 
las  plantillas.  Por  omision,  esta  es  una  tupla  vacia.  Elige  un  directorio  en  el  que  desees 
guardar  tus  plantillas  y agrega  este  a TEMPLATE_DIRS,  asi: 

TEMPLATE_DIRS  = ( 

'/home/django/misitio/templates', 

) 

Hay  algunas  cosas  que  notar: 

■ Puedes  especificar  cualquier  directorio  que  quieras,  siempre  y cuando  la 
cuenta  de  usuario  en  la  cual  se  ejecuta  el  servidor  web  tengan  acceso  al 
directorio  y a su  contenido.  Si  no  puedes  pensar  en  un  lugar  apropiado  para 
poner  las  plantillas,  te  recomendamos  crear  un  directorio  templates  dentro 
del  proyecto  de  Django  (esto  es,  dentro  del  directorio  misitio  que  creaste  en  el 
capitulo  2,  si  vienes  siguiendo  los  ejemplos  a lo  largo  del  libro). 

■ Si  tu  variable  TEMPLATE_DIRS  contiene  unicamente  un  directorio,  jno 
olvides  poner  una  coma  al  final  de  la  cadena  de  texto! 

Mai: 

# iOlvidaste  la  coma! 

TEMPLATE_DIRS  = ( 

'/home/django/misitio/templates' 

) 
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Bien: 

# La  coma  en  el  lugar  correcto. 

TEMPLATE_DIRS  = ( 

'/home/django/misitio/templates', 

) 


Python  requiere  una  coma  en  las  tuplas  de  un  solo  elemento  para 
diferenciarlas  de  una  expresion  de  parentesis.  Este  es  un  error  muy  comun  en 
los  usuarios  nuevos. 

■ Si  estas  en  Windows,  incluye  la  letra  de  tu  unidad  y usa  el  estilo  de  Unix  para 
las  barras  en  vez  de  barras  invertidas,  como  sigue: 

TEMPLATE_DIRS  = ( 

'C:/www/django/templates\ 

) 

■ Es  muy  sencillo  usar  rutas  absolutas  (esto  es,  las  rutas  de  directorios 
comienzan  desde  la  raiz  del  sistema  de  archivos).  Pero  si  quieres  ser  un  poco 
mas  flexible  e independiente,  puedes  tomar  el  hecho  de  que  el  archivo  de 
configuration  de  Django  es  solo  codigo  Python  y construir  la  variable 
TEMPLATE_DIRS  dinamicamente,  por  ejemplo: 

import  os. path 

TEMPLATE_DIRS  = ( 

os.path.join(os.path.dirname( file ),  ’templates'). replace('\V,7'), 

) 

Este  ejemplo  usa  la  variable  “magica”  de  Python  file , la  cual  es 

automaticamente  asignada  al  nombre  del  archivo  del  modulo  de  Python  en  el 
que  se  encuentra  el  codigo. 

Con  la  variable  TEMPLATE_DIRS  configurada,  el  proximo  paso  es  cambiar  el 
codigo  de  vista,  para  que  use  la  funcionalidad  automatica  de  carga  de  plantillas  de 
Django,  para  no  incluir  la  ruta  de  la  plantilla  en  la  vista,  solo  el  nombre. 

Volvamos  a la  vista  fecha_actual  y hagamosle  algunos  cambios: 


views . py 


import  datetime 

from  django. template. loader  import  get_template 
from  django. template  import  Context 
from  django. http  import  HttpResponse 

def  fecha_actual(request): 

ahora  = datetime. datetime. now() 

t = get_templateCfecha_actual.html) 

html  = t.render(Context({'fecha_actual':  ahora})) 

return  HttpResponse(html) 

En  este  ejemplo,  usamos  la  funcion  django.template.loader.get_template()  en  vez 
de  cargar  la  plantilla  desde  el  sistemas  de  archivos  manualmente.  La  funcion 
get_template()  toma  el  nombre  de  la  plantilla  como  argumento,  se  da  cuenta  en 
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donde  esta  la  plantilla  en  el  sistema  de  archivos,  la  abre,  y retorna  el  objeto  Template 
compilado. 

La  plantilla  de  nuestro  ejemplo  es  fecha_actual.html,  pero  no  hay  nada  especial 
acerca  de  la  extension  .html.  Tu  puedes  darle  la  extension  que  quieras  a tus 
aplicaciones  o puedes  omitir  las  extensiones. 

Para  determinar  la  localization  de  las  plantillas  en  tu  sistema  de  archivos 
get_template()  combina  el  directorio  de  plantillas  de  la  variable  TEMPLATE_DIRS 
con  el  nombre  que  le  pasamos  al  metodo  get_template().  Por  ejemplo  si  la  variable 
TEMPLATE_DIRS  es  '/home/django/misitio/templates',  el  metodo  get_template() 
buscara  las  plantillas  en  /home/django/misitio/templates/fecha_actual.html. 

41  ft  localhost:8000/fecha/  ’C  P ft  (£)  4-  # = 

T emplateDoesNotExist  at  /fecha/  □ 

fecha_actual.html 

Request  Method:  GET 

Request  URL:  http://localhost:8000/fecha/ 

Django  Version:  1.8 
Exception  Type:  TemplateDoesNotExist 
Exception  Value:  fecha_actual.html 


Imagen  4.1  Pagina  de  error  que  muestra  cuando  una  plantilla  no  se  encuentra 

Si  get_template()  no  puede  encontrar  la  plantilla  con  el  nombre  pasado,  esta 
levanta  una  exception  TemplateDoesNotExist.  Para  ver  que  como  se  ve  esto,  ejecuta 
el  servidor  de  desarrollo  de  Django  otra  vez,  ejecutando  python  manage.py  runserver 
en  el  directorio  de  tu  proyecto  de  Django.  Luego,  escribe  en  tu  navegador  la  pagina 
que  activa  la  vista  fecha_actual  (o  sea,  http://127.0.0.1:8000/fecha/).  Asumiendo  que 
tu  variable  de  configuration  DEBUG  esta  asignada  a True  y que  todavia  no  hayas 
creado  la  plantilla  fecha_actual.html,  deberias  ver  una  pagina  de  error  de  Django 
resaltando  el  error  TemplateDoesNotExist. 

Esta  pagina  de  error  es  similar  a la  que  explicamos  en  el  capitulo  3,  con  una  pieza 
adicional  de  information  de  depuration:  una  section  “Postmortem  del  cargador  de 
plantillas”.  Esta  section  te  indica  que  plantilla  intento  cargar  Django  acompanado  de 
una  razon  para  cada  intento  fallido  (por  ej.  “File  does  not  exist”).  Esta  information  es 
invaluable  cuando  hacemos  depuration  de  errores  de  carga  de  plantillas. 

<■  & Iocalhost8000/fecha/  C P ^ ♦ # = 

Cargador  de  plantillas  postmortem 

Django  intento  buscar  las  plantillas,  en  este  orden: 

• UsandO  los  cargadores:  django.  template. loaders,  filesystem. Loader: 

o C:  \Users\saul\Desktop\misitio\misitio\templates\fecha_actual.html  (File  does  not  exist) 

• UsandO  los  cargadores:  d j ango  . template  . loaders . app_directori.es . Loader: 

Traza  Cambiar  vista  a copiar  v peqar 

c: \Python27\lib\site-packages\django-l . 8-py2 . 7 . egg\django\core\handlers\base -py in  get_response 

113.  response  = wrapped  callback (request,  *callback  args,  ■‘"''callback  kwargs)  ... 

► Local  vars 

C:\Users\saul\Desktop\misitio\misitio\view3.py  in  fecha_actual 

44.  return  render (request,  1 fecha_actual.html' , { * fecha  actual ' : ahora})  ... 


Imagen  4.2  Pagina  de  error  que  muestra  la  section  postmortem. 

Como  probablemente  puedas  distinguir  de  los  mensajes  de  error  de  la  figura 
anterior  Django  intento  buscar  una  plantilla  combinando  el  directorio  de  la  variable 
TEMPLATE_DIRS  con  el  nombre  de  la  plantilla  pasada  a get_template()-  Entonces  si 
tu  variable  TEMPLATE_DIRS  contiene  '/home/django/templates',  Django  buscara 
7home/django/templates/fecha_actual.htmr.  Si  TEMPLATE_DIRS  contiene  mas 
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que  un  directorio,  cada  uno  de  estos  es  examinado  hasta  que  se  encuentre  la  plantilla 
o hasta  que  no  haya  mas  directorio  s. 

Continuando,  crea  el  archivo  fecha_actual.html  en  tu  directorio  de  plantillas 
usando  el  siguiente  codigo: 


misitio/misitio/ templates/ fecha_actual . html 


<html><body>Hoy  es  {{ fecha_actual  }}.</bodyx/html> 

Refresca  la  pagina  en  tu  navegador  web,  y deberias  ver  la  pagina  completamente 
renderizada. 

RenderO 

Hemos  visto  como  cargar  una  plantilla,  rellenar  un  Context  y retornar  un  objeto 
HttpResponse  con  el  resultado  de  la  plantilla  renderizada.  Lo  hemos  optimizado  para 
usar  get_template()  en  lugar  de  mezclar  la  plantilla  y hemos  usado  las  rutas  de 
busqueda  de  las  plantillas.  Pero  seguimos  requiriendo  tipear  una  cantidad 
considerable  de  cosas.  Sin  embargo  esto  es  tan  comun  que  Django  provee  un  atajo 
que  te  deja  hacer  todas  estas  cosas,  en  una  sola  linea  de  codigo. 

Este  atajo  es  la  funcion  llamada  render!) , la  cual  se  encuentra  en  el  modulo 
django. shortcuts.  La  mayoria  de  las  veces,  usaras  render!)  en  vez  de  cargar  las 
plantillas  manualmente  y crear  los  objetos  Context  y HttpResponse  manualmente.  - 
a menos  que  te  paguen  por  el  total  de  lineas  que  escribas. 

Aqui  esta  el  ejemplo  que  hemos  venido  usando  fecha_actual  reescrito  utilizando  el 
metodo-atajo  render!): 


views . py 


import  datetime 

from  django. shortcuts  import  render 

def  fecha_actual(request): 

ahora  = datetime. datetime. now() 

return  render(request,  'fecha_actual.htm I',  {'fecha_actual':  ahora}) 

jQue  diferencia!  Veamos  paso  a paso,  los  cambios  que  hicimos  al  codigo: 

■ Ya  no  tenemos  que  importar  get_template,  Template,  Context,  o 
HttpResponse.  En  vez  de  eso,  solo  importamos  el  atajo 
django. shortcuts.render,  mientras  que  import  datetime  se  mantiene. 

■ En  la  funcion  fecha_actual,  seguimos  calculando  la  variable:  ahora,  pero  de  la 
carga  de  la  plantilla,  la  creacion  del  contexto,  la  renderizacion,  y la  creacion  de 
HttpResponse  se  encarga  la  llamada  a render!).  Como  render!)  retorna  un 
objeto  HttpResponse,  podemos  simplemente  retornar  ese  valor  en  la  vista, 
ysencillo  no? 

El  primer  argumento  de  render!)  debe  ser  el  nombre  de  la  plantilla  a utilizar.  El 
segundo  argumento,  si  es  pasado,  debe  ser  un  diccionario  para  usar  en  la  creacion  de 
un  Context  para  esa  plantilla.  Si  no  se  le  pasa  un  segundo  argumento,  render  utilizara 
un  diccionario  vacio. 
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Subdirectorios  en  get_template() 

Puede  ser  un  poco  inmanejable  guardar  todas  las  plantillas  en  un  solo  directorio. 
Quizas  quieras  guardar  las  plantillas  en  subdirectorios  del  directorio  de  tus  plantillas, 
y esto  esta  bien.  De  hecho,  recomendamos  hacerlo;  algunas  de  las  caracteristicas  mas 
avanzadas  de  Django  (como  las  vistas  genericas  del  sistema,  las  cuales  veremos  en  el 
capitulo  11)  esperan  esta  distribution  de  las  plantillas  como  una  convention  por 
omision. 

Guardar  las  plantillas  en  subdirectorios  de  tu  directorio  de  plantilla  es  facil.  En  tus 
llamadas  a get_template(),  solo  incluye  el  nombre  del  subdirectorio  y una  barra  antes 
del  nombre  de  la  plantilla,  asi: 

t = get_template(,aplicacion/fecha_actual.html') 

Debido  a que  render()  es  un  pequeno  contenedor  de  get_template(),  puedes  hacer 
lo  mismo  con  el  primer  argumento  de  render. 

return  render(request,  'aplicacion/fecha_actual.htmr,  {'fecha_actual':  ahora}) 

No  hay  limites  para  la  profundidad  del  arbol  de  subdirectorios.  Sientete  libre  de 
usar  tantos  como  quieras  o necesites. 


NOTA:  Para  usuarios  de  Windows,  es  necesario  asegurar  el  uso  de  barras  comunes 
en  vez  de  barras  invertidas.  get_template()  asume  el  estilo  de  designation  de  archivos 
usado  en  Unix. 


La  etiqueta  de  plantilla  include 

Ahora  que  hemos  visto  en  funcionamiento  el  mecanismo  para  cargar  plantillas, 
podemos  introducir  un  tipo  de  plantilla  incorporada  que  tiene  una  ventaja  para  esto: 
{%  include  %}.  Esta  etiqueta  te  permite  incluir  el  contenido  de  otra  plantilla.  El 
argumento  para  esta  etiqueta  deberia  ser  el  nombre  de  la  plantilla  a incluir,  y el 
nombre  de  la  plantilla  puede  ser  una  variable  string  hard-coded  (entre  comillas), 
entre  simples  o dobles  comillas.  En  cualquier  momento  que  tengas  el  mismo  codigo 
en  varias  etiquetas,  considera  utilizar  la  etiqueta  {%  include  %}  para  eliminar  la 
redundancia  entre  las  plantillas. 

Estos  dos  ejemplos  incluyen  el  contenido  de  la  plantilla  nav.html.  Los  ejemplos  son 
equivalentes  e ilustran  que  cualquier  modo  de  comillas  esta  permitido: 

{%  include  'nav.html'  %} 

{%  include  "nav.html"  %} 

Este  ejemplo  incluye  el  contenido  de  la  plantilla  includes /nav.html: 

{%  include  'includes/nav.html'  %} 

Este  ejemplo  incluye  el  contenido  de  la  plantilla  cuyo  nombre  se  encuentra  en  la 
variable  template_name: 


{%  include  template_name  %} 
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Como  en  get_templateO,  el  nombre  del  archivo  de  la  plantilla  es  determinado 
agregando  el  directorio  de  plantillas  tornado  de  TEMPLATE_DIRS  para  el  nombre  de 
plantilla  solicitado. 

Las  plantillas  incluidas  son  evaluadas  con  el  contexto  de  la  plantilla  en  la  cual  esta 
incluida. 

Considera  estos  dos  ejemplos: 


mipagina . html 


<html> 

<body> 

{%  include  "includes/nav.html"  %} 
<hl>{{  titulo  }}</hl> 

</body> 

</html> 


includes /nav . html 


<div  id="nav"> 

Tu  estas  en:  {{  seccion_actual }} 

</div> 

Si  renderizas  mipagina.html  con  un  contexto  que  contiene  la  variable  seccion_ 
actual,  la  variable  estara  disponible  en  la  plantilla  “incluida”  tal  como  esperarias. 

Si  una  plantilla  no  encuentra  la  etiqueta  {%  include  %},  Django  hara  una  de  estas 
dos  cosas: 

1.  Si  DEBUG  es  True,  veras  la  exception  TemplateDoesNotExist  sobre  la  pagina 
de  error  de  Django. 

2.  Si  DEBUG  es  False,  la  etiqueta  fallara  silenciosamente,  sin  mostrar  nada  en  el 
lugar  de  la  etiqueta. 


Herencia  de  plantillas 

Nuestras  plantillas  de  ejemplo  hasta  el  momento  han  sido  fragmentos  de  HTML,  pero 
en  el  mundo  real,  usaras  el  sistema  de  plantillas  de  Django  para  crear  paginas  HTML 
enteras.  Esto  conduce  a un  problema  comun  en  el  desarrollo  web:  jComo  reducimos 
la  duplication  y la  redundancia  de  las  areas  comunes  de  las  paginas,  como  por 
ejemplo,  los  paneles  de  navegacion? 

Una  forma  clasica  de  solucionar  este  problema  es  usar  includes,  insertando  dentro 
de  las  paginas  HTML  a “incluir”  una  pagina  dentro  de  otra.  Es  mas,  Django  admite 
esta  aproximacion,  con  la  etiqueta  {%  include  %}  anteriormente  descrita.  Pero  la 
mejor  forma  de  solucionar  este  problema  con  Django  es  usar  una  estrategia  mas 
elegante  llamada  herencia  de  plantillas. 

En  esencia,  la  herencia  de  plantillas  te  deja  construir  una  plantilla  base  “esqueleto” 
que  contenga  todas  las  partes  comunes  de  tu  sitio  y definir  “bloques”  que  las 
plantillas  hijas  puedan  sobrescribir. 

Veamos  un  ejemplo  de  esto  creando  una  plantilla  completa  para  nuestra  vista 
fecha_actual,  edita  el  archivo  fecha_actual.html  asi: 
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misitio/misitio/ templates/ fecha_actual . html 


<!DOCTYPE  HTML  PUBLIC  "-//W3C//DTD  HTML  4.01//EN"> 

<html  lang="en"> 

<head> 

<title>Fecha  Actual</title> 

</head> 

<body> 

<hl>Mi  util  sitio</hl> 

<p>Hoy  es:  fecha_actual  }}.</p> 

<hr> 

<p>Gracias  por  visitar  nuestro  sitio  web.</p> 

</body> 

</html> 

Esto  se  ve  bien,  pero  ^Que  sucede  cuando  queremos  crear  una  plantilla  para  otra 
vista  -digamos,  ^La  vista  horas_adelante  del  capitulo  3*  Si  queremos  hacer 
nuevamente  una  plantilla  completa  agradable  y valida,  creariamos  algo  como  esto: 


<!DOCTYPE  HTML  PUBLIC  "-//W3C//DTD  HTML  4.01//EN"> 

<html  lang="en"> 

<head> 

<title>Fecha  Futura</title> 

</head> 

<body> 

<hl>Mi  util  sitio</hl> 

<p>En  {{  horas_adelante  }}  hora(s),  sera  {{  hora_siguiente  }}.</p> 

<hr> 

<p>Gracias  por  visitar  nuestro  sitio  web.</p> 

</body> 

</html> 

Claramente,  estariamos  duplicando  una  cantidad  considerable  de  codigo  HTML. 
Imagina  si  tuvieramos  mas  cosas  tipicas,  como  barras  de  navegacion,  algunas  hojas 
de  estilo,  quizas  algo  de  JavaScript  - terminariamos  poniendo  todo  tipo  de  HTML 
redundante  en  cada  plantilla-. 

La  solution  a este  problema,  es  usar  “includes”  en  el  servidor  para  sacar  factor 
comun  de  las  plantillas  y guardarlas  en  recortes  de  plantillas  separados,  que  luego 
son  incluidos  en  cada  plantilla.  Quizas  quieras  guardar  la  parte  superior  de  la 
plantilla  en  un  archivo  llamado  cabecera_pagina.html: 

<!DOCTYPE  HTML  PUBLIC  "-//W3C//DTD  HTML  4.01//EN"> 

<html  lang="en"> 

<head> 

Y quizas  quieras  guardar  la  parte  inferior  en  un  archivo  llamado  pie_pagina.html: 

<hr> 

<p>Gracias  por  visitar  nuestro  sitio  web.</p> 

</body> 

</html> 

Con  una  estrategia  basada  en  “includes”,  la  cabecera  y la  parte  de  abajo  son  faciles. 
Es  el  medio  el  que  queda  desordenado.  En  este  ejemplo,  ambas  paginas  contienen  un 
titulo  - <hl>Mi  util  sitio</hl>  pero  ese  titulo  no  puede  encajar  dentro  de 
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header.html  porque  el  <title>  en  las  dos  paginas  es  diferente.  Si  incluimos  <hl>  en  la 
cabecera,  tendriamos  que  incluir  <title>,  lo  cual  no  permitiria  personalizar  este  en 
cada  pagina.  ^Ves  a donde  queremos  llegar? 

El  sistema  de  herencia  de  Django  soluciona  estos  problemas.  Lo  puedes  pensar  a 
esto  como  la  version  contraria  a la  del  lado  del  servidor.  En  vez  de  deflnir  los  pedazos 
que  son  comunes,  solo  defines  los  pedazos  que  son  diferentes. 

El  primer  paso  es  definir  una  plantilla  base  - un  “esqueleto”  de  tu  pagina  que  las 
planliHas At/Av  llenaran  luego. 

Aqui  hay  una  plantilla  para  nuestro  ejemplo  actual: 


misitio/misitio/ templates/base . html 


<!DOCTYPE  HTML  PUBLIC  "-//W3C//DTD  HTML  4.01//EN"> 

<html  lang="en"> 

<head> 

<title>{%  block  title  %}{%  endblock  %}</title> 

</head> 

<body> 

<hl>Mi  sitio  Web</hl> 

{%  block  content  %}{%  endblock  %} 

{%  block  footer  %} 

<hr> 

<p>Gracias  por  visitar  nuestro  sitio  web.</p> 

{%  endblock  %} 

</body> 

</html> 

Esta  plantilla,  que  llamamos  base.html,  define  un  esqueleto  E1TML  o mejor  dicho 
define  la  estructura  del  documento,  que  usaremos  para  todas  las  paginas  del  sitio.  Es 
trabajo  de  las  plantillas  hijas  sobrescribir,  agregar,  dejar  vacio  el  contenido  de  los 
bloques.  (Si  continuas  siguiendo  los  ejemplos,  guarda  este  archivo  en  tu  directorio  de 
plantillas). 

Usamos  una  etiqueta  de  plantillas  nueva  aqui:  la  etiqueta  {%  block  %}.  Todas  las 
etiquetas  {%  block  %},  le  indican  al  motor  de  plantillas  que  una  plantilla  hija,  quizas 
sobrescriba  esa  parte  de  la  plantilla. 

Ahora  que  tenemos  una  plantilla  base,  podemos  modilicar  nuestra  plantilla 
existente  fecha_actual  para  usar  la  etiqueta  extends  y usar  la  plantilla  base.html: 


misitio/misitio/ templates/ fecha_actual . html 


{%  extends  "base.html"  %} 

{%  block  title  %}La  fecha  actual{%  endblock  %} 

{%  block  content  %} 

<p>Hoy  es:  {{ fecha_actual  }}</p> 

{%  endblock  %} 

Siguiendo  con  el  tema  de  plantillas,  vamos  a crear  una  plantilla  para  la  vista 
horas_adelante  del  capitulo  3.  (Si  estas  siguiendo  los  ejemplos,  cambia  el  codigo  de  la 
vista  horas_adelante  para  que  use  el  sistema  de  plantillas). 

La  funcion  vista  del  el  archivo  views.py  queda  de  la  siguiente  forma,  incluyendo  la 
vista  anterior: 
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views . py 


import  datetime 

from  django. shortcuts  import  render 

def  fecha_actual(request): 

ahora  = datetime. datetime. now() 

return  render(request,  'fecha_actual.htm I',  {'fecha_actual':  ahora}) 

def  horas_adelante(request,  horas): 

try: 

horas  = int(horas) 
except  ValueError: 
raise  Http404() 

dt  = datetime,  datetime.  now()  + datetime.  timedelta(hours=horas) 

return  render(request,  'horas_adelante.html',  {'hora_siguiente':  dt,  'horas':  horas  }) 

Y esta  es  la  plantilla  para  horas_adelante.html: 


misitio/misitio/ templates/horas_adelante . html 


{%  extends  "base.html"  %} 

{%  block  title  %}Fecha  Futura{%  endblock  %} 

{%  block  content  %} 

<p>En  {{  horas  }}  horas(s),  la  fecha  sera:  {{  hora_siguiente  }}.</p> 

{%  endblock  %} 

^No  es  hermoso?  Cada  plantilla  contiene  solo  el  codigo  que  es  diferente  para  esa 
plantilla.  No  necesita  redundancia.  Si  necesitas  hacer  un  cambio  radical  en  el 
diseno  del  sitio  Web,  solo  cambia  la  plantilla  base.html,  y todas  las  demas  plantillas 
reflejaran  los  cambios  inmediatamente. 

Veamos  como  trabaja: 

Cuando  cargamos  una  plantilla,  por  ejemplo  fecha_actual.html,  el  motor  de 
plantillas  ve  la  etiqueta  {%  extends  %},  nota  que  esta  plantilla  es  la  hija  de  otra.  El 
motor  inmediatamente  carga  la  plantilla  padre  -en  este  caso,  base.html. 

Hasta  este  punto,  el  motor  de  la  plantilla  nota  las  tres  etiquetas  {%  block  %}  en 
base.html  y reemplaza  estos  bloques  por  el  contenido  de  la  plantilla  hija.  Entonces,  el 
titulo  que  definimos  en  el  bloque  {%  block  title  %}  sera  usado,  asi  como  el  que 
definimos  en  el  bloque  {%  block  content  %}. 

Nota  que  la  plantilla  hija  no  define  el  bloque  footer,  entonces  el  sistema  de 
plantillas  usa  el  valor  de  la  plantilla  padre  por  defecto.  El  contenido  de  la  etiqueta  {% 
block  %}  en  la  plantilla  padre  es  usado  siempre  que  no  se  sobrescribe  en  una  plantilla 
hija. 

La  herencia  no  afecta  el  funcionamiento  del  contexto,  y puedes  usar  tantos  niveles 
de  herencia  como  necesites.  Una  forma  comun  de  utilizar  la  herencia  es  el  siguiente 
enfoque  de  tres  niveles: 

1.  Crea  una  plantilla  base.html  que  contenga  el  aspecto  principal  de  tu  sitio.  Esto 
es  lo  que  rara  vez  cambiara,  si  es  que  alguna  vez  cambia. 
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2.  Crea  una  plantilla  base_SECTION.html  para  cada  “section”  de  tu  sitio  (por  ej. 
base_fotos.html  y base_foro.html).  Esas  plantillas  heredan  de  base.html  e 
incluyen  secciones  especificas  de  estilo  y diseno. 

3.  Crea  una  plantilla  individual  para  cada  tipo  de  pagina,  tales  como  paginas  de 
formulario  o galena  de  fotos.  Estas  plantillas  heredan  de  la  plantilla  solo  la 
seccion  apropiada. 

Esta  aproximacion  maximiza  la  reutilizacion  de  codigo  y hace  mas  facil  agregar 
elementos  para  compartir  distintas  areas,  como  puede  ser  un  navegador  de  seccion, 
un  contenido  o una  cabecera. 

Aqui  hay  algunos  consejos  para  trabajar  con  la  herencia  de  plantillas: 

■ Si  usas  etiquetas  {%  extends  %}  en  la  plantilla,  esta  debe  ser  la  primera 
etiqueta  de  esa  plantilla.  En  otro  caso,  la  herencia  no  funcionara. 

* Generalmente,  cuanto  mas  etiquetas  {%  block  %}  tengas  en  tus  plantillas, 
mejor.  Recuerda,  las  plantillas  hijas  no  tienen  que  definir  todos  los  bloques 
del  padre,  entonces  puedes  rellenar  un  numero  razonable  de  bloques  por 
omision,  y luego  definir  solo  lo  que  necesiten  las  plantillas  hijas.  Es  mejor 
tener  mas  conexiones  que  menos. 

■ Si  encuentras  codigo  duplicado  en  un  numero  de  plantillas,  esto 
probablemente  signifique  que  debes  mover  ese  codigo  a un  {%  block  %}  en  la 
plantilla  padre. 

■ Si  necesitas  obtener  el  contenido  de  un  bloque  desde  la  plantilla  padre,  la 
variable  {{  block.super  }}  hara  este  truco.  Esto  es  util  si  quieres  agregar 
contenido  del  bloque  padre  en  vez  de  sobreescribirlo  completamente. 

■ No  puedes  definir  multiples  etiquetas  {%  block  %}  con  el  mismo  nombre  en  la 
misma  plantilla.  Esta  limitation  existe  porque  una  etiqueta  bloque  trabaja  en 
ambas  direcciones.  Esto  es,  una  etiqueta  bloque  no  solo  provee  un  agujero  a 
llenar,  sino  que  tambien  define  el  contenido  que  llenara  ese  agujero  en  el 
padre.  Si  hay  dos  nombres  similares  de  etiquetas  {%  block  %}  en  una  plantilla, 
el  padre  de  esta  plantilla  puede  no  saber  cual  de  los  bloques  usar  (aunque 
usara  el  primero  que  encuentre). 

■ El  nombre  de  plantilla  pasado  a {%  extends  %}  es  cargado  usando  el  mismo 
metodo  que  get_template().  Esto  es,  el  nombre  de  la  plantilla  es  agregado  a la 
variable  TEMPLATE  JDIRS. 

■ En  la  mayoria  de  los  casos,  el  argumento  para  {%  extends  %}  sera  un  string  o 
cadena,  pero  tambien  puede  ser  una  variable,  si  no  sabes  el  nombre  de  la 
plantilla  padre  hasta  la  ejecucion.  Esto  te  permite  hacer  cosas  divertidas  y 
dinamicas. 

<?,Que  sigue? 

Los  sitios  Web  modernos,  son  manejados  con  una  base  de  dates,  el  contenido  de  la 
pagina  Web  esta  guardado  en  una  base  de  datos  relational.  Esto  permite  una  clara 
separation  entre  los  datos  y la  logica  de  los  datos  (de  la  misma  forma  en  que  las  vistas 
y las  plantillas  permiten  una  separation  de  la  logica  y la  vista).  El  proximo  capitulo 
cubre  las  herramientas  que  Django  brinda  para  interactuar  con  bases  de  datos. 
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Interactuando  con  una  base 
de  datos:  Modelos 


El  capitulo  3,  cubrio  los  conceptos  fundamentales  sobre  la  construction  dinamica 
de  sitios  web  con  Django,  asi  como  la  configuration  de  vistas  y URLconfs.  Como 
explicamos,  una  vista  es  responsable  de  implementar  alguna  Idgica  arbitraria  y luego 
retornar  una  respuesta.  En  el  ejemplo,  nuestra  logica  arbitraria  era  calcular  la  fecha  y 
la  hora  actual. 

En  las  aplicaciones  web  modernas,  la  logica  arbitraria  a menudo  implica 
interactuar  con  una  base  de  datos.  Detras  de  escena,  un  sitio  web  impulsado  por  una 
base  de  datos  se  conecta  a un  servidor  de  base  de  datos,  recupera  algunos  datos  de 
este,  y los  muestra  con  un  formato  agradable  en  una  pagina  web,  del  mismo  modo  el 
sitio  puede  proporcionar  funcionalidad  que  permita  a los  visitantes  del  sitio  ingresar 
datos  a la  base  de  datos;  por  su  propia  cuenta. 

Muchos  sitios  web  complejos  proporcionan  alguna  combinacion  de  las  dos, 
Amazon.com  por  ejemplo,  es  un  buen  ejemplo  de  un  sitio  que  maneja  una  base  de 
datos.  Cada  pagina  de  un  producto  es  esencialmente  una  consulta  a la  base  de  datos 
de  productos  de  Amazon  formateada  en  HTML,  y cuando  envias  una  opinion  de 
cliente  ( customer  review),  esta  es  insertada  en  la  base  de  datos  de  opinio nes. 

Django  es  apropiado  para  crear  sitios  web  que  manejen  una  base  de  datos,  ya  que 
incluye  una  manera  facil  pero  poderosa  de  realizar  consultas  a bases  de  datos 
utilizando  Python.  Este  capitulo  explica  esta  funcionalidad:  la  capa  de  la  base  de 
datos  de  Django. 


Nota:  Aunque  no  es  estrictamente  necesario  conocer  teoria  basica  sobre  bases  de 
datos  y SQL  para  usar  la  capa  de  la  base  de  datos  de  Django,  es  altamente 
recomendado.  Una  introduccion  a estos  conceptos  va  mas  alia  del  alcance  de  este 
libro,  pero  continua  leyendo  si  eres  nuevo  en  el  tema. 

De  seguro  seras  capaz  de  seguir  adelante  y captar  los  conceptos  basicos  en  base  al 
contexto  y los  ejemplos. 


La  manera  “tonta”  de  hacer  una  consulta  a la 
base  de  datos  en  las  vistas 


Asi  como  en  el  capitulo  3 detallamos  la  manera  “tonta”  de  producir  una  salida  con  la 
vista  (codificando  en  duro  el  texto  directamente  dentro  de  la  vista),  hay  una  manera 
“tonta”  de  recuperar  datos  desde  una  base  de  datos  en  una  vista.  Esto  es  simple:  solo 


74  CAPITULO  5 MODELOS 


usa  una  biblioteca  de  Python  existente  para  ejecutar  una  consulta  SQL  y haz  algo  con 
los  resultados. 

En  este  ejemplo  de  una  vista,  usamos  la  biblioteca  MySQLdb  (disponible  en 

® http://www.djangoproject.eom/r/python-mysql/)  para  conectarnos  a una  base  de 
datos  de  MySQL,  recuperar  algunos  registros  e introducirlos  en  una  plantilla  para 
mostrar  una  pagina  web: 

import  MySQLdb 

from  django. shortcuts  import  render 
def  lista_biblioteca(request): 

db  = MySQLdb. connect(user='yo',  db-datos.db',  passwd-admin’,  host-localhost') 
cursor  = db.cursor() 

cursor. execute('SELECT  nombre  FROM  biblioteca  ORDER  BY  nombre') 

names  = [row[0]  for  row  in  cursor. fetchallQ] 

db.close() 

return  render(request,  'listajibros.html',  {'nombres':  nombres}) 

Este  enfoque  funciona,  pero  inmediatamente  se  hacen  evidentes  algunos 
problemas: 

■ Estamos  codificando  en  duro  ( hard-coding)  los  parametros  de  la  conexion  a la 
base  de  datos.  Lo  ideal  seria  que  esos  parametros  se  guardarse  en  la 
configuration  de  Django. 

■ Tenemos  que  escribir  una  gran  cantidad  de  codigo  repetitivo:  crear  una 
conexion,  un  cursor,  ejecutar  una  sentencia,  y cerrar  la  conexion.  Lo  ideal 
seria  que  todo  lo  que  tuvieramos  que  hacer  fuera  especiflcar  los  resultados 
que  queremos  obtener. 

■ Nos  ata  a MySQL.  Si,  en  el  camino,  cambiamos  de  MySQL  a PostgreSQL, 
tenemos  que  usar  un  adaptador  de  base  de  datos  diferente  (por  ej.  psycopg  en 
vez  de  MySQLdb),  alterar  los  parametros  de  conexion  y - dependiendo  de  la 
naturaleza  de  las  sentencia  de  SQL,  posiblemente  reescribir  el  SQL.  La  idea  es 
que  el  servidor  de  base  de  datos  que  usemos  este  abstraido,  entonces  el 
pasarnos  a otro  servidor  podria  significar  realizar  un  cambio  en  un  unico 
lugar. 

Como  esperabas,  la  capa  de  la  base  de  datos  de  Django  apunta  a resolver  estos 
problemas.  Este  es  un  adelanto  de  como  la  vista  anterior  puede  ser  reescrita  usando 
la  API  de  Django: 

from  django. shortcuts  import  render_to_response 
from  misitio. biblioteca. models  import  Libro 

def  lista_biblioteca(request): 

listajibros  = Libro. objects. order_by('nombre') 

return  render_to_response('lista_libros.htmr,  {'listajibros':  listajibros}) 


Explicaremos  este  codigo  un  poco  mas  adelante,  en  este  capitulo.  Por  ahora,  solo 
observa  la  forma  en  que  lo  escribimos,  usando  la  capa  de  modelos  de  Django. 
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El  patron  de  diseno  MTV 

Antes  de  profundizar  de  lleno  en  el  codigo,  tomemonos  un  momento  para  considerar 
el  diseno  global  de  una  aplicacion  Web  Django  impulsada  por  una  base  de  datos. 

Como  mencionamos  en  los  capitulos  anteriores,  Django  fue  disenado  para 
promover  el  acoplamiento  debil  y la  estricta  separacion  entre  las  piezas  de  una 
aplicacion.  Si  sigues  esta  filosofia,  es  facil  hacer  cambios  en  un  lugar  particular  de  la 
aplicacion  sin  afectar  otras  piezas. 

En  las  funciones  de  vista,  por  ejemplo,  discutimos  la  importancia  de  separar  la 
logica  de  negocios,  de  la  logica  de  presentacion  usando  un  sistema  de  plantillas.  Con 
la  capa  de  la  base  de  datos,  aplicamos  esa  misma  filosofia  para  el  acceso  logico  a los 
datos. 

Estas  tres  piezas  juntas  - la  logica  de  acceso  a la  base  de  datos,  la  logica  de 
negocios,  y la  logica  de  presentacion  - comprenden  un  concepto  que  a veces  es 
llamado  el  patron  de  arquitectura  de  software  Modelo-  Visla-Conlrolador  (MVC) . En 
este  patron,  el  “Modelo”  hace  referencia  al  acceso  a la  capa  de  datos,  la  “Vista”  se 
refiere  a la  parte  del  sistema  que  selecciona  que  mostrar  y como  mostrarlo,  y el 
“Controlador”  implica  la  parte  del  sistema  que  decide  que  vista  usar,  dependiendo  de 
la  entrada  del  usuario,  accediendo  al  modelo  si  es  necesario. 


POR  QUE  EL  ACRONIMO? 


El  objetivo  de  definir  en  forma  explicita  patrones  tales  como  MVC  es  principalmente, 
para  simplificar  la  comunicacion  entre  los  desarrolladores.  En  lugar  de  tener  que 
decide  a tus  companeros  de  trabajo,  “Vamos  a hacer  una  abstraccion  del  acceso  a la 
base  de  datos,  luego  vamos  a crear  una  capa  que  se  encarga  de  mostrar  los  datos,  y 
vamos  a poner  una  capa  en  el  medio  para  que  regule  esto”,  puedes  sacar  provecho  de 
un  vocabulario  compartido  y decir,  “Vamos  a usar  un  patron  de  diseno  MVC  aqui”. 

Django  sigue  el  patron  MVC  tan  al  pie  de  la  letra  que  puede  ser  llamado  un 
framework  MVC.  Someramente,  la  M,  V y C se  separan  en  Django  de  la  siguiente 
manera: 

■ M,  la  porcion  de  acceso  a la  base  de  datos,  es  manejada  por  la  capa  de  la  base 
de  datos  de  Django,  la  cual  describiremos  en  este  capitulo. 

■ K la  porcion  que  selecciona  que  datos  mostrar  y como  mostrarlos,  es 
manejada  por  la  vista  y las  plantillas. 

■ C,  la  porcion  que  delega  a la  vista  dependiendo  de  la  entrada  del  usuario,  es 
manejada  por  el  framework  mismo  siguiendo  tu  URLconf  y llamando  a la 
funcion  apropiada  de  Python  para  la  URL  obtenida. 

Debido  a que  la  “C”  es  manejada  por  el  mismo  framework  y la  parte  mas 
emocionante  se  produce  en  los  modelos,  las  plantillas  y las  vistas,  Django  es 
conocido  como  un  Framework  MTV.  En  el  patron  de  diseno  MTV. 

■ Msignifica  “Model”  (Modelo),  la  capa  de  acceso  a la  base  de  datos.  Esta  capa 
contiene  toda  la  informacion  sobre  los  datos:  como  acceder  a estos,  como 
validarlos,  cual  es  el  comportamiento  que  tiene,  y las  relaciones  entre  los 
datos. 
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■ T significa  “Template”  (Plantilla),  la  capa  de  presentation.  Esta  capa  contiene 
las  decisiones  relacionadas  a la  presentation:  como  algunas  cosas  son 
mostradas  sobre  una  pagina  web  o otro  tipo  de  documento. 

■ Vsignifica  “View”  (Vista),  la  capa  de  la  logica  de  negocios.  Esta  capa  contiene 
la  logica  que  accede  al  modelo  y la  delega  a la  plantilla  apropiada:  puedes 
pensar  en  esto  como  un  puente  entre  los  modelos  y las  plantillas. 

Si  estas  familiarizado  con  otros  frameworks  de  desarrollo  web  MVC,  como  Ruby  on 
Rails,  quizas  consideres  que  las  vistas  de  Django  pueden  ser  el  “controlador”  y las 
plantillas  de  Django  pueden  ser  la  “vista”.  Esto  es  una  confusion  desafortunada  a raiz 
de  las  diferentes  interpretaciones  de  MVC.  En  la  interpretation  de  Django  de  MVC,  la 
“vista”  describe  los  datos  que  son  presentados  al  usuario;  no  necesariamente  el  como 
se  mostraran,  pero  si  cuales  datos  son  presentados.  En  contraste,  Ruby  on  Rails  y 
frameworks  similares  sugieren  que  el  trabajo  del  controlador  incluya  la  decision  de 
cuales  datos  son  presentados  al  usuario,  mientras  que  la  vista  sea  estrictamente  el 
como  seran  presentados  y no  cuales. 

Ninguna  de  las  interpretaciones  es  mas  “correcta”  que  otras.  Lo  importante  es 
entender  los  conceptos  subyacentes. 

Configuracion  de  la  base  de  datos 

Con  toda  esta  filosofia  en  mente,  vamos  a comenzar  a explorar  la  capa  de  la  base  de 
datos  de  Django.  Primero,  necesitamos  tener  en  cuenta  algunas  configuraciones 
iniciales:  necesitamos  indicarle  a Django  que  servidor  de  base  de  datos  usar  y como 
conectarse  al  mismo. 

Asumiremos  que  ya  haz  configurado  un  servidor  de  base  de  datos,  lo  has  activado, 
y has  creado  una  base  de  datos  en  este  punto  (por  ej.  usando  la  sentencia  CREATE 
DATABASE).  SQLite  es  un  caso  especial;  ya  que  en  este  caso,  no  hay  que  crear  una 
base  de  datos  manualmente,  porque  SQLite  usa  un  archivo  autonomo  sobre  el 
sistema  de  archivos  para  guardar  los  datos  y Django  lo  crea  automaticamente. 

Como  con  TEMPLATE_DIRS  en  los  capitulos  anteriores,  la  configuracion  de  la  base 
de  datos  se  encuentra  en  el  archivo  de  configuracion  de  Django,  llamado,  por 
omision,  settings.py.  Edita  este  archivo  y busca  las  opciones  de  la  variable 
DATABASES,  el  cual  es  un  diccionario  que  contiene  los  ajustes  necesarios,  para 
configurar  la  base  datos: 

ENGINE  = ' ' 

NAME  = ' ' 

USER  = ' ' 

PASSWORD  = ' ' 

HOST  = ' ' 

DATABASE_PORT  = ' ' 

Aqui  hay  un  resumen  de  cada  propiedad. 

■ ENGINE:  le  indica  a Django  que  base  de  datos  utilizar.  Si  usas  una  base  de  datos 

con  Django,  ENGINE  debe  configurarse  con  una  cadena  de  los  mostrados  en  la 

Tabla5-1. 
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Configuracion 

Base  de  datos  Adaptador  requerido 

django.db.backends.postgresqLps 

ycopg2 

PostgreS 

QL 

Psycopg  version  2.x, 

http : / / www.  dj  ango  pro  j ect.com/r/p 

ython-pgsql/. 

django.db.backends.mysql 

MySQL 

MySQLdb, 

http : / / www.  dj  angopr  o j ect . co  m / r / p 
ython-mysql/. 

django.db.backends.sqlite3 

SQLite 

No  necesita  adaptador 

dj  ango . db  .backends . o racle 

Oracle 

cx_Oracle, 

http://www.djangoproject.eom/r/p 
ython- oracle/. 

Tabla  5.1  Adaptadores  requeridos  en  Django 


□ Nota:  Cualquiera  que  sea  la  base  de  datos  que  uses,  necesitaras  descargar  e 
instalar  el  adaptador  apropiado.  Cada  uno  de  estos  esta  disponible  libremente  en 
la  web;  solo  sigue  el  enlace  en  la  columna  “Adaptador  requerido”  en  la  Tabla  5-1. 


■ NAME  la  indica  a Django  el  nombre  de  tu  base  de  datos.  Si  estas  usando  SQLite, 
especifica  la  ruta  completo  del  sistema  de  archivos  hacia  el  archivo  de  la  base  de 
datos  (porej.  '/home/django/datos.db'). 

■ USER  le  indica  a Django  cual  es  el  nombre  de  usuario  a usar  cuando  se  conecte 
con  tu  base  de  datos.  Si  estas  usando  SQLite,  deja  este  en  bianco. 

■ PASSWORD  le  indica  a Django  cual  es  la  contrasena  a utilizar  cuando  se  conecte 
con  tu  base  de  datos.  Si  estas  utilizando  SQLite  o tienes  una  contrasena  vacia, 
deja  este  en  bianco. 

■ HOST  le  indica  a Django  cual  es  el  host  a usar  cuando  se  conecta  a tu  base  de 
datos.  Si  tu  base  de  datos  esta  sobre  la  misma  computadora  que  la  instalacion  de 
Django  (o  sea  localhost),  deja  este  en  bianco.  Si  estas  usando  SQLite,  deja  este  en 
bianco. 

MySQL  es  un  caso  especial  aqui.  Si  este  valor  comienza  con  una  barra  ('/')  y estas 
usando  MySQL,  MySQL  se  conectara  al  socket  especificado  por  medio  de  un 
socket  Unix,  por  ejemplo: 

DATABASEJHOST  = '/var/run/mysql' 

Si  estas  utilizando  MySQL  y este  valor  no  comienza  con  una  barra,  entonces  este 
valor  es  asumido  como  el  host. 

■ PORT  le  indica  a Django  que  puerto  usar  cuando  se  conecte  a la  base  de  datos.  Si 
estas  utilizando  SQLite,  deja  este  en  bianco.  En  otro  caso,  si  dejas  este  en  bianco, 
el  adaptador  de  base  de  datos  subyacente  usara  el  puerto  por  omision  acorde  al 
servidor  de  base  de  datos.  En  la  mayoria  de  los  casos,  el  puerto  por  omision  esta 
bien,  por  lo  tanto  puedes  dejar  este  en  bianco. 
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La  variable  DATABASES,  por  omision  usa  la  configuration  mas  simple  posible,  la 
cual  esta  configurada  para  utilizar  SQLite,  por  lo  que  no  tendras  que  configurar  nada, 
si  vas  a usar  SQLite  como  base  de  datos: 

DATABASES  = { 

'default':  { 

'ENGINE':  ’django.db. backends. sqlite3\ 

’NAME':  os.path.join(BASE_DIR,  'db.sqlite3’), 

} 


Sin  embargo  si  quieres  usar  otra  base  de  datos  como  MySQL,  Oracle,  o PostgreSQL 
es  necesario  especificar  algunos  parametros  adicionales,  que  seran  requeridos  en  el 
archivo  de  configuration. 

El  siguiente  ejemplo  asume  que  quieres  utilizar  PostgreSQL: 

DATABASES  = { 

'default':  { 

'ENGINE':  'django.db. backends. postgresql  psycopg2', 

'NAME':  'basedatos.bd', 

'USER':  'yo', 

'PASSWORD':  'admin', 

'HOST':  '127.0.0.1', 

'PORT':  '5432', 

} 

} 


Como  podras  darte  cuenta,  lo  unico  que  necesitas  cambiar  es  la  'ENGINE',  si 
quieres  usar  MySQL  e introducir  los  datos  apropiados  de  acuerdo  a la  base  de  datos 
que  estes  usando. 

Una  vez  que  hayas  ingresado  estas  configuraciones,  compruebalas.  Primero,  desde 
el  directorio  del  proyecto  que  creaste  en  el  capitulo  2,  ejecuta  el  comando: 

python  manage. py  shell 

Notaras  que  comienza  un  interprete  interactivo  de  Python.  Las  apariencias  pueden 
enganar.  Hay  una  diferencia  importante  entre  ejecutar  el  comando  manage. py  shell 
dentro  del  directorio  del  proyecto  de  Django  y el  interprete  generico  python.  El 
ultimo  es  el  Python  shell  basico,  pero  el  anterior  le  indica  a Django  cuales  archivos  de 
configuration  usar  antes  de  comenzar  el  shell. 

Este  es  un  requerimiento  clave  para  realizar  consultas  a la  base  de  datos:  Django 
necesita  saber  cuales  son  los  archivos  de  configuraciones  a usar  para  obtener  la 
information  de  la  conexion  a la  base  de  datos. 

Detras  de  escena,  manage.py  shell  simplemente  asume  que  tu  archivo  de 
configuration  esta  en  el  mismo  directorio  que  manage.py.  Hay  otras  maneras  de 
indicarle  a Django  que  modulo  de  configuration  usar,  pero  este  topico  lo  cubriremos 
mas  adelante.  Por  ahora,  usa  manage.py  shell  cuando  necesites  hacer  modificaciones 
y consultas  especificas  a Django. 

Una  vez  que  hayas  entrado  al  shell,  escribe  estos  comandos  para  probar  la 
configuration  de  tu  base  de  datos: 

»>  from  django.db  import  connection 
»>  cursor  = connection. cursor() 

»> 
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Si  no  sucede  nada,  entonces  tu  base  de  datos  esta  configurada  correctamente.  De 
lo  contrario  revisa  el  mensaje  de  error  para  obtener  un  indicio  sobre  que  es  lo  que 
esta  mal.  La  Tabla  5-2  muestra  algunos  mensajes  de  error  comunes. 


Mensaje  de  error 

Solution 

You  haven't  set  the  ENGINE  setting  yet. 

Configura  la  variable  ENGINE  con  otra  cosa 
que  no  sea  un  string  vacio.  Observa  los 
valores  de  la  tabla  5-1. 

Environment  variable 
DJANGO_SETTINGS_MODULE  is 
undefined. 

Ejecuta  el  comando  python  manage.py 
shell  en  vez  de  python. 

Error  loading  module:  No 

module  named 

No  tienes  instalado  el  modulo  apropiado 
para  la  base  de  datos  especificada  (por  ej. 
psycopg  o MySQLdb).(Es  tu 

responsabilidad  instalarlos) 

isn't  an  available  database 
backend. 

Configura  la  variable  ENGINE  con  un 
motor  valido  descrito  previamente. 
^Habras  cometido  un  error  de  tipeo? 

database  does  not  exist 

Cambia  la  variable  NAME  para  que  apunte 
a una  base  de  datos  existente,  o ejecuta  la 
sentencia  CREATE  DATABASE  apropiada 
para  crearla. 

role  does  not  exist 

Cambia  la  variable  USER  para  que  apunte  a 
un  usuario  que  exista,  o crea  el  usuario  en 
tu  base  de  datos. 

could  not  connect  to  server 

Asegurate  de  que  HOST  y PORT  esta 
configurados  correctamente  y que  el 
servidor  este  corriendo. 

Tabla  5.2  Mensajes  de  error 

Tu  primera  aplicacion 

Ahora  que  verificamos  que  la  conexion  esta  funcionando,  es  hora  de  crear  una 
Aplicacion  de  Django  - una  coleccion  de  archivos  de  codigo  fuente,  incluyendo 
modelos  y vistas,  que  conviven  en  un  solo  paquete  de  Python  y representen  una 
aplicacion  completa  de  Django. 

Vale  la  pena  explicar  la  terminologia  aqui,  porque  esto  es  algo  que  suele  hacer 
tropezar  a los  principiantes.  Ya  hemos  creado  un  proyecto,  en  el  capitulo  2,  entonces, 
jcual  es  la  diferencia  entre  un  proyecto  y una  aplicacion^.  Bueno,  la  diferencia  es  la 
que  existe  entre  la  configuration  y el  codigo: 

■ Un  proyecto  es  una  instancia  de  un  cierto  conjunto  de  aplicaciones  de  Django, 
mas  las  configuraciones  de  esas  aplicaciones.  Tecnicamente,  el  unico 
requerimiento  de  un  proyecto  es  que  este  suministre  un  archivo  de  configuration 
o settings.py,  el  cual  define  la  information  hacia  la  conexion  a la  base  de  datos,  la 
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lista  de  las  aplicaciones  instaladas,  la  variable  TEMPLATEJDIRS,  y asi 
sucesivamente. 

■ Una  aplicacion  es  un  conjunto  portable  de  alguna  funcionalidad  de  Django, 
tipicamente  incluye  modelos  y vistas,  que  conviven  en  un  solo  paquete  de  Python 
(Aunque  el  unico  requerimiento  es  que  contenga  una  archivo  models.py). 

Por  ejemplo,  Django  incluye  un  numero  de  aplicaciones,  tales  como  un  framework 
geografico  “Geodejango”  y una  interfaz  de  administration  automatica.  Una  cosa 
clave  para  notar  sobre  las  aplicaciones  es  que  son  portables  y reusables  en  multiples 
proyectos. 

Elay  pocas  reglas  estrictas  sobre  como  encajar  el  codigo  Django  en  este  esquema; 
ya  que  es  muy  flexible.  Si  estas  construyendo  un  sitio  web  simple,  quizas  uses  solo 
una  aplicacion.  Si  estas  construyendo  un  sitio  web  complejo  con  varias  piezas  que  no 
se  relacionan  entre  si,  tal  como  un  sistema  de  comercio  electronico  o un  foro, 
probablemente  quieras  dividirlo  en  aplicaciones  para  que  te  sea  posible  rehusar 
piezas  individualmente  en  un  futuro. 

Es  mas,  no  necesariamente  debes  crear  aplicaciones  en  absoluto,  como  lo  hace 
evidente  la  funcion  de  la  vista  del  ejemplo  que  creamos  antes  en  este  libro.  En  estos 
casos,  simplemente  creamos  un  archivo  llamado  views.py,  llenamos  este  con  una 
funcion  de  vista,  y apuntamos  nuestra  URLconf  a esa  funcion.  No  se  necesitan 
“aplicaciones”. 

No  obstante,  existe  un  requisito  respecto  a la  convention  de  la  aplicacion:  si  estas 
usando  la  capa  de  base  de  datos  de  Django  (modelos),  debes  crear  una  aplicacion  de 
Django.  Los  modelos  deben  vivir  dentro  de  aplicaciones. 

Siguiendo  con  el  ejemplo,  dentro  del  directorio  del  proyecto  misitio  que  creaste  en 
el  capitulo  2,  escribe  este  comando  para  crear  una  nueva  aplicacion  a la  que 
llamaremos  biblioteca: 

python  manage. py  startapp  biblioteca 

Este  comando  no  produce  ninguna  salida,  pero  crea  un  directorio  llamado  biblioteca 
dentro  del  directorio  misitio  y dentro  de  este  crea  otro  directorio  mas,  llamado 
migrations. 

Echemos  un  vistazo  al  contenido: 

biblioteca/ 

init . py 

admin . py 
models . py 
tests . py 
views . py 
migrations/ 

init . py 


Estos  archivos  contendran  los  modelos,  las  vistas,  las  pruebas,  y las  migraciones 
para  esta  aplicacion,  aprenderemos  como  usarlos  en  los  siguientes  capitulos. 

Echa  un  vistazo  a models.py,  admin. py,  views.py,  tests. py  en  tu  editor  de  texto 
favorito.  Estos  archivos  estan  vacios,  excepto  por  las  importaciones.  Este  es  el  espacio 
disponible  para  ser  creativo  con  tu  aplicacion  de  Django. 
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Definir  modelos  en  Python 

Como  discutimos  en  los  capitulos  anteriores,  la  “M”  de  “MTV”  hace  referenda  al 
“Modelo”.  Un  modelo  de  Django  es  una  description  de  los  datos  en  la  base  de  datos, 
representada  como  codigo  de  Python.  Esta  es  tu  capa  de  datos  - lo  equivalente  de  tu 
sentencia  SQL  CREATE  TABLE,  excepto  que  estan  en  Python  en  vez  de  SQL,  e incluye 
mas  que  solo  definition  de  columnas  de  la  base  de  datos.  Django  usa  un  modelo  para 
ejecutar  codigo  SQL  detras  de  escena  y retornar  estructuras  de  datos  convenientes  en 
Python  representando  las  filas  de  las  tablas  de  la  base  de  datos.  Django  tambien  usa 
modelos  para  representar  conceptos  de  alto  nivel  que  no  necesariamente  pueden  ser 
manejados  por  SQL. 

Si  estas  familiarizado  con  base  de  datos,  inmediatamente  podria  pensar,  “^No  es 
redundante  definir  modelos  de  datos  en  Python  yen  SQL?”  Django  trabaja  de  este 
modo  por  varias  razones: 

■ La  introspection  requiere  overhead  y es  imperfecta.  Con  el  objetivo  de 
proveer  una  API  conveniente  de  acceso  a los  datos,  Django  necesita  conocer 
de  alguna  forma  la  capa  de  la  base  de  datos,  y hay  dos  formas  de  lograr  esto. 
La  primera  seria  describir  expllcitamente  los  datos  en  Python,  y la  segunda 
seria  la  introspection  de  la  base  de  datos  en  tiempo  de  ejecucion  para 
determinar  el  modelo  de  la  base  de  datos. 

La  segunda  forma  parece  tiara,  porque  los  metadatos  sobre  tus  tablas  se 
alojan  en  un  unico  lugar,  pero  introduce  algunos  problemas.  Primero, 
introspeccionar  una  base  de  datos  en  tiempo  de  ejecucion  obviamente 
requiere  overead  o sobrecarga.  Si  el  framework  tuviera  que  introspeccionar  la 
base  de  datos  cada  vez  que  se  procese  una  petition,  o incluso  cuando  el 
servidor  web  sea  inicializado,  esto  podria  provocar  un  nivel  de  sobrecarga 
inaceptable.  (Mientras  algunos  creen  que  el  nivel  de  overhead  es  aceptable, 
los  desarrolladores  de  Django  apuntan  a quitar  del  framework  tanto  overhead 
como  sea  posible,  y esta  aproximacion  hace  que  Django  sea  mas  rapido  que 
los  frameworks  competidores  de  alto  nivel  en  mediciones  de  desempeno). 
Segundo,  algunas  bases  de  datos,  notablemente  viejas  versiones  de  MySQL, 
no  guardan  suficiente  metadatos  para  asegurarse  una  completa  introspection. 

■ Escribir  Python  es  divertido,  y dejar  todo  en  Python  limita  el  numero  de  veces 
que  tu  cerebro  tiene  que  realizar  un  “cambio  de  contexto”.  Si  te  mantienes  en 
un  solo  entorno/mentalidad  de  programacion  tanto  tiempo  como  sea  posible, 
ayuda  para  la  productividad.  Teniendo  que  escribir  SQL,  luego  Python,  y 
luego  SQL  otra  vez  es  perjudicial. 

■ Tener  modelos  de  datos  guardados  como  codigo  en  vez  de  en  tu  base  de  datos 
hace  facil  dejar  tus  modelos  bajo  un  control  de  versiones.  De  esta  forma, 
puedes  facilmente  dejar  rastro  de  los  cambios  a tu  capa  de  modelos. 

■ SQL  permite  solo  un  cierto  nivel  de  metadatos  acerca  de  un  layout  de  datos. 
La  mayoria  de  sistemas  de  base  de  datos,  por  ejemplo,  no  provee  un  tipo  de 
datos  especializado  para  representar  una  direction  web  o de  email.  Los 
modelos  de  Django  si.  La  ventaja  de  un  tipo  de  datos  de  alto  nivel  es  la  alta 
productividad  y la  reusabilidad  de  codigo. 

■ SQL  es  inconsistente  a traves  de  distintas  plataformas.  Si  estas 
redistribuyendo  una  aplicacion  web,  por  ejemplo,  es  mucho  mas  pragmatico 
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distribuir  un  modulo  de  Python  que  describa  tu  capa  de  datos  que  separar 
conjuntos  de  sentencias  CREATE  TABLE  para  MySQL,  PostgreSQL  y SQLite. 

Una  contra  de  esta  aproximacion,  sin  embargo,  es  que  es  posible  que  el  codigo 
Python  quede  fuera  de  sincronia  respecto  a lo  que  hay  actualmente  en  la  base.  Si 
haces  cambios  en  un  modelo  Django,  necesitaras  hacer  los  mismos  cambios  dentro 
de  tu  base  de  datos  para  mantenerla  consistente  con  el  modelo.  Detallaremos 
algunas  estrategias  para  manejar  este  problema  mas  adelante  en  este  capitulo. 

Finalmente,  Django  incluye  una  utilidad  que  puede  generar  modelos  haciendo 
introspection  sobre  una  base  de  datos  existente.  Esto  es  util  para  comenzar  a trabajar 
rapidamente  sobre  datos  heredados. 


Tu  primer  Modelo 

Para  empezar  a trabajar  con  ejemplos,  en  este  capitulo  y en  el  siguiente  nos 
enfocaremos  en  crear  una  configuracion  de  datos  basica  sobre  libro/autor/editor 
(una  biblioteca).  Usaremos  este  ejemplo  porque  las  relaciones  conceptuales  entre 
libros,  autores  y editores  son  bien  conocidas,  y es  una  configuracion  de  base  datos 
comunmente  utilizada,  en  una  biblioteca  online,  ademas  de  que  se  usa  en  muchos 
lugares  como  texto  introductorio  a SQL.  Por  otra  parte,  jestas  leyendo  un  libro  que 
fue  escrito  por  autores  y producido  por  un  editor! 

Asumiremos  los  siguientes  conceptos,  campos  y relaciones: 

■ Un  autor  tiene  un  nombre,  apellidos,  un  correo  electronico... 

■ Un  editor  tiene  un  nombre,  un  domicilio,  una  ciudad,  un  estado  o provincia, 
un  pais  y un  sitio  Web. 

■ Un  libro  tiene  un  titulo  y una  fecha  de  publication.  Tambien  tiene  uno  o mas 
autores  (una  relacion  muchos-a-muchos  con  autores)  y un  unico  editor  (una 
relacion  uno  a muchos  - tambien  conocida  como  clave  foranea  - con 
editores). 

El  primer  paso  para  utilizar  esta  configuracion  de  base  de  datos  con  Django  es 
expresarla  como  codigo  Python.  En  el  archivo  models. py  que  se  creo  con  el  comando 
startapp,  ingresa  lo  siguiente: 


biblioteca/models . py 


from  django.db  import  models 

class  Editor(models. Model): 

nombre  = models.  CharField(max_length=30) 
domicilio  = models.  CharField(max_length=50) 
ciudad  = models.  CharField(max_length=60) 
estado  = models.  CharField(max_length=30) 
pais  = models.  CharField(max_length=50) 
website  = models. URLFieldQ 

class  Autor(models. Model): 

nombre  = models.  CharField(max_length=30) 
apellidos  = models.  CharField(max_length=40) 
email  = models.  EmailFieldQ 
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class  Libro(models. Model): 

titulo  = models. CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 
editor  = models. ForeignKey(Editor) 
fecha_publicacion  = models. DateField() 
portada  = models. lmageField(upload_to='portadas') 

Examinemos  rapidamente  este  codigo  para  conocer  lo  basico.  La  primera  cosa  a 
notar  es  que  cada  modelo  es  representado  por  una  clase  Python  que  es  una  subclase 
de  django.db. models. Model.  La  clase  antecesora,  Model,  contiene  toda  la  maquinaria 
necesaria  para  hacer  que  estos  objetos  sean  capaces  de  interactuar  con  la  base  de 
datos  y que  hace  que  nuestros  modelos  solo  sean  responsables  de  definir  sus  campos, 
en  una  sintaxis  compacta  y agradable.  Lo  creas  o no,  este  es  todo  el  codigo  que 
necesitamos  para  tener  acceso  basico  a los  datos  con  Django. 

Cada  modelo  generalmente  corresponde  a una  tabla  unica  de  la  base  de  datos,  y 
cada  atributo  de  un  modelo  generalmente  corresponde  a una  columna  en  esa  tabla. 
El  nombre  de  atributo  corresponde  al  nombre  de  columna,  y el  tipo  de  campo  (ej.: 
CharLield)  corresponde  al  tipo  de  columna  de  la  base  de  datos  (ej.:  varchar).  Por 
ejemplo,  el  modelo  Editor  es  equivalente  a la  siguiente  tabla  (asumiendo  la  sintaxis 
de  PostgreSQL  para  CREATE  TABLE): 

CREATE  TABLE  "Editor"  ( 

"id"  serial  NOT  NULL  PRIMARY  KEY, 

"nombre"  varchar(30)  NOT  NULL, 

"domicilio"  varchar(50)  NOT  NULL, 

"ciudad"  varchar(60)  NOT  NULL, 

"estado"  varchar(30)  NOT  NULL, 

"pais"  varchar(50)  NOT  NULL, 

"website"  varchar(200)  NOT  NULL 

); 


En  efecto,  Django  puede  generar  esta  sentencia  CREATE  TABLE  automaticamente 
como  veremos  en  un  momento. 

La  exception  a la  regia  una-clase-por-tabla  es  el  caso  de  las  relaciones  muchos-a- 
muchos.  En  nuestros  modelos  de  ejemplo,  libro  tiene  un  ManyToManyField  llamado 
autor.  Esto  significa  que  un  libro  tiene  uno  o mas  autores,  pero  la  tabla  de  la  base  de 
datos  libro  no  tiene  una  columna  autores.  En  su  lugar,  Django  crea  una  tabla 
adicional  - una  “tabla  de  join”  muchos-a-muchos  - que  maneja  la  correlation  entre 
biblioteca  y autores. 

Para  una  lista  completa  de  todos  los  tipos  de  campo  y las  distintas  opciones  de 
sintaxis  de  modelos,  consulta  el  apendiceB. 

Finalmente,  debes  notar  que  no  hemos  definido  explicitamente  una  clave  primaria 
en  ninguno  de  estos  modelos.  A no  ser  que  le  indiques  lo  contrario,  Django  dara 
automaticamente  a cada  modelo  un  campo  de  clave  primaria,  llamado  id.  Es  un 
requerimiento  el  que  cada  modelo  Django  tenga  una  clave  primaria  de  columna 
simple. 


Instalando  el  modelo 

Ya  escribimos  el  codigo;  ahora  necesitamos  crear  las  tablas  en  la  base  de  datos.  Para 
ello,  el  primer  paso  es  activar  estos  modelos  en  nuestro  proyecto  Django.  Elacemos 
esto  agregando  la  aplicacion  biblioteca  a la  lista  de  aplicaciones  instaladas  en  el 
archivo  de  configuration. 
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Edita  el  archivo  settings.py  y examina  la  variable  de  configuracion 
INSTALLED_APPS,  INSTALLED_APPS  le  indica  a Django  que  aplicaciones  estan 
activadas  para  un  proyecto  determinado.  Por  defecto  esta  se  ve  asi: 

INSTALLED_APPS  = ( 

'django.contrib. admin', 

'django.contrib.auth', 

'django.contrib. contenttypes', 

'django.contrib. sessions', 

'django.contrib.  messages', 

'django.contrib. staticfiles', 

) 


Agrega  tu  aplicacion  'biblioteca'  a la  lista  de  INSTALLED_APPS,  de  manera  que  la 
configuracion  termine  viendose  asi: 

INSTALLED_APPS  = ( 

'django.contrib. admin', 

'django.contrib.auth', 

'django.contrib. contenttypes', 

'django.contrib. sessions', 

'django.contrib.  messages', 

'django.contrib. staticfiles', 

'biblioteca', 

) 

(Como  aqui  estamos  tratando  con  una  tupla  de  un  solo  elemento,  no  olvides  la  coma 
al  final.  De  paso,  los  autores  de  este  libro  prefieren  poner  una  coma  despues  de  cada 
elemento  de  una  tupla,  aunque  la  tupla  tenga  solo  un  elemento.  Esto  evita  el 
problema  de  olvidar  comas,  y no  hay  penalization  por  el  use  de  esa  coma  extra) 

Ten  en  cuenta  que  biblioteca  se  refiere  a la  aplicacion  biblioteca  en  la  que  estamos 
trabajando.  Cada  aplicacion  en  INSTALLED_APPS  es  representada  por  su  ruta  Python 
completa  - esto  es,  la  ruta  de  paquetes,  separados  por  puntos,  que  lleva  al  paquete  de 
la  aplicacion. 


Nota:  Si  estas  usando  PostgreSQL,  Oracle  o MySQL,  debes  asegurarte  de  crear  una 
base  de  datos  en  este  punto.  Lo  puedes  hacer  con  el  comando  “CREATE  DATABASE 
nombre_base_de_datos;”  mediante  el  interprete  interactivo  de  la  base  de  datos. 

Asegurate  de  instalar  la  libreria  de  image nes  Pillow,  para  validar  imagenes  ya  que 
Django  la  utiliza  para  comprobar  que  los  objetos  que  sean  subidos  a un  campo 
ImageField  sean  imagenes  validas,  de  lo  contrario  Django  se  quejara  si  intentas  usar 
un  campo  ImageField  sin  tener  instalada  la  libreria  Pillow.  Para  instalarla  usa  el 
comando: 

pip  install  pillow 

Tambien  agrega  la  ruta  al  directorio  en  donde  se  guardaran  las  imagenes, 
especificandolo  en  el  archivo  de  configuraciones  setings.py  y usando  la  variable 
MEDIA_ROOT: 


MEDIA  ROOT  = 'media/' 
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Y La  URL  que  se  encargara  de  servir  dichas  imageries  MEDIAJJRL,  por  ejemplo 
asumiendo  que  estas  usando  el  servidor  de  desarrollo: 

MEDIAJJRL  = 'http://localhost:8000/media/' 


Si  estas  usando  SQLite  no  necesitaras  crear  nada  de  antemano  -la  base  de  datos  se 
creara  automaticamente  cuando  esta  se  necesite.  Ahora  que  la  aplicacion  Django  ha 
sido  activada  en  el  archivo  de  configuration,  podemos  crear  las  tablas  en  nuestra 
base  de  datos.  Primero,  validemos  los  modelos  ejecutando  este  comando: 

El  comando  validate  verifica  si  la  sintaxis  y la  logica  de  tus  modelos  son  correctas.  Si 
todo  esta  bien,  veras  el  mensaje  0 errors  found.  Si  no,  asegurate  de  haber  escrito  el 
codigo  del  modelo  correctamente.  La  salida  del  error  debe  brindarte  information  util 
acerca  de  que  es  lo  que  esta  mal  en  el  codigo. 

Cada  vez  que  piensas  que  tienes  problemas  con  tus  modelos,  ejecuta  manage.py 
validate.  Tiende  a capturar  todos  los  problemas  comunes  del  modelo. 

Si  tus  modelos  son  validos,  ejecuta  el  siguiente  comando  para  que  Django 
compruebe  la  sintaxis  de  tus  modelos  en  la  aplicacion  biblioteca: 

python  manage.py  check  biblioteca 

El  comando  check  verifica  que  todo  este  en  orden  respecto  a tus  modelos,  no  crea 
ni  toca  de  ninguna  forma  tu  base  de  datos  - solo  imprime  una  salida  en  la  pantalla  en 
la  que  identifica  posibles  errores  en  tus  modelos. 

Una  vez  que  todo  esta  en  orden,  necesitamos  guardar  las  migraciones  para  los 
modelos  en  un  archivo  de  control,  para  que  Django  pueda  encontrarlas  al  sincronizar 
el  esquema  de  la  base  de  datos.  Ejecuta  el  comando  makemigrations  de  esta  manera: 

python  manage.py  makemigrations 

Veras  algo  como  esto: 

Migrations  for  'biblioteca': 

0001_initial . py : 

- Create  model  Editor 

- Create  model  Autor 

- Create  model  Libro 

Una  vez  que  usamos  el  comando  makemigrations,  para  crear  las  "migraciones", 
podemos  usar  el  comando  sqlmigrate  para  ver  el  SQL  generado.  El  comando 
sqlmigrate  toma  los  nombres  de  las  migraciones  y las  retorna  en  un  lenguaje  SQL,  por 
cada  aplicacion  especificada,  de  la  siguiente  forma: 

python  manage.py  sqlmigrate  biblioteca  0001 

En  este  comando,  biblioteca  es  el  nombre  de  la  aplicacion  y 0001,  es  el  numero 
que  Django  asigna  como  nombre  a cada  migration  o cambio  hecho  al  esquema  de  la 
base  de  datos  (mira  dentro  de  la  carpeta  migrations).  Cuando  ejecutes  el  comando, 
debes  ver  algo  como  esto  (formateado  para  legibilidad,  usando  SQLite): 

BEGIN; 

CREATE  TABLE  "biblioteca_editor"  ( 

"id"  integer  NOT  NULL  PRIMARY  KEY  AUTOINCREMENT, 
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"nombre"  varchar(30)  NOT  NULL, 

"domicilio"  varchar(50)  NOT  NULL, 

"ciudad"  varchar(60)  NOT  NULL, 

"estado"  varchar(30)  NOT  NULL, 

"pais"  varchar(50)  NOT  NULL, 

"website"  varchar(200)  NOT  NULL 

) 

CREATE  TABLE  "biblioteca_autor"  ( 

"id"  integer  NOT  NULL  PRIMARY  KEY  AUTOINCREMENT, 

"nombre"  varchar(30)  NOT  NULL, 

"apellidos"  varchar(40)  NOT  NULL, 

"email"  varchar(75)  NOT  NULL 

) 

CREATE  TABLE  "biblioteca_libro_autores"  ( 

"id"  integer  NOT  NULL  PRIMARY  KEY  AUTOINCREMENT, 

"librojd"  integer  NOT  NULL, 

"autorjd"  integer  NOT  NULL  REFERENCES  "biblioteca_autor"  ("id"), 

UNIQUE  ("librojd",  "autorjd") 

) 

CREATE  TABLE  "bibliotecajibro"  ( 

"id"  integer  NOT  NULL  PRIMARY  KEY  AUTOINCREMENT, 

"titulo"  varchar(lOO)  NOT  NULL, 

"editorjd"  integer  NOT  NULL  REFERENCES  "biblioteca_editor"  ("id"), 
"fecha_publicacion"  date  NOT  NULL, 

"portada"  varchar(lOO)  NOT  NULL 

) 

i 

CREATE  INDEX  "bibliotecajibro_autores_dd67bl09"  ON  "bibliotecaJibro_autores" 
("librojd"); 

CREATE  INDEX  "bibliotecajibro_autores_40e8bcf3"  ON  "bibliotecaJibro_autores" 
("autorjd"); 

CREATE  INDEX  "bibliotecaJibro_c2be667f"  ON  "bibliotecajibro"  ("editorjd"); 

COMMIT; 


Observa  lo  siguiente: 

■ Los  nombres  de  tabla  se  generan  automaticamente  combinando  el  nombre  de 
la  aplicacion  (biblioteca)  y el  nombre  en  minusculas  del  modelo  (Editor, 
Libro,  y Autor).  Puedes  sobrescribir  este  comportamiento,  como  se  detalla  en 
el  Apendice  B. 

■ Como  mencionamos  antes,  Django  agrega  una  clave  primaria  para  cada  tabla 
automaticamente  - los  campos  id.  Tambien  puedes  sobrescribir  esto. 

■ Por  convention,  Django  agrega  "Jd"  al  nombre  de  campo  de  las  claves 
foraneas.  Como  ya  puedes  imaginar,  tambien  puedes  sobrescribir  esto. 

■ La  relation  de  clave  foranea  se  hace  explicita  con  una  sentencia  REFERENCES 
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■ Estas  sentencias  CREATE  TABLE  son  adaptadas  a medida  de  la  base  de  datos 
que  estas  usando,  de  manera  que  Django  maneja  automaticamente  los  tipos 
de  campo  especificos  de  cada  base  de  datos,  como  auto_increment  (MySQL), 
serial  (PostgreSQL),  o integer  primary  key  (SQLite),  por  ti.  Lo  mismo  sucede 
con  el  uso  de  las  comillas  simples  o dobles  en  los  nombres  de  columna.  La 
salida  del  ejemplo  esta  en  la  sintaxis  de  PostgreSQL. 

El  comando  sqlmigrate  no  crea  ni  toca  de  ninguna  forma  tu  base  de  datos  - solo 
imprime  una  salida  en  la  pantalla  para  que  puedas  ver  que  SQL  ejecutaria  Django  si 
le  pidieras  que  lo  hiciera.  Si  quieres,  puedes  copiar  y pegar  este  fragmento  de  SQL  en 
tu  cliente  de  base  de  datos,  o usa  los  pipes  o tuberias  de  Unix  (|)  para  pasarlo 
directamente.  De  todas  formas,  Django  provee  una  manera  mas  facil  de  confirmar  el 
envio  del  SQL  a la  base  de  datos. 

Una  vez  creado  las  migraciones  con  makemigrations,  es  necesario  sincronizar  los 
cambios  en  la  base  de  datos,  ya  que  si  ejecutas  python  manage.py  makemigrations  de 
nuevo  nada  sucede,  porque  no  has  agregado  ningun  modelo  a la  aplicacion 
biblioteca  ni  has  incorporado  ninguna  aplicacion  en  INSTALLED_APPS.  Por  lo  que, 
siempre  es  seguro  ejecutar  python  manage.py  makemigrations  - no  hara 
desaparecer,  ni  aparecer  cosas  magicamente. 

Ahora  para  realizar  los  cambios  al  esquema  de  la  base  de  datos  es  necesario  usar  el 
comando  migrate,  que  se  encarga  de  crear  las  tablas  de  la  base  de  datos: 

python  manage.py  migrate 

Y muestra  por  salida  algo  asi: 

Operations  to  perform: 

Synchronize  unmigrated  apps:  (none) 

Apply  all  migrations:  biblioteca 
Synchronizing  apps  without  migrations: 

Creating  tables . . . 

Installing  custom  SQL... 

Installing  indexes... 

Running  migrations: 

Applying  biblioteca. 0001_initial .. . OK 

El  comando  migrate  es  una  simple  sincronizacion  de  tus  modelos  hacia  tu  base  de 
datos.  Este  comando  examina  todos  los  modelos  en  cada  aplicacion  que  figure  en  tu 
variable  de  configuration  INSTALLED_APPS,  verifica  la  base  de  datos  para  ver  si  las 
tablas  apropiadas  ya  existen,  y las  crea  si  no  existen. 

El  comando  migrate  toma  todas  las  migraciones  que  se  han  aplicado  al  proyecto 
(ya  que  Django  rastrea  cada  una  de  las  migraciones  aplicadas,  usando  una  tabla 
especial  llamada  django_migrations),  esencialmente  las  ejecuta  de  nuevo  contra  la 
base  de  datos,  sincronizando  los  cambios  hechos  a los  modelos  con  el  esquema  de  la 
base  de  datos. 

Las  migraciones  son  muy  poderosas  y nos  permiten  cambiar  los  modelos  cada 
cierto  plazo  de  tiempo,  como  cuando  estamos  desarrollando  nuestro  proyecto,  sin  la 
necesidad  de  borrar  las  tablas  o borrar  la  base  de  datos  actual  y crear  otra  - el 
proposito  de  las  migraciones  consiste  en  actualizar  la  base  de  datos  que  usamos,  sin 
perder  datos. 

Los  tres  pasos  que  seguimos  para  crear  cambios  en  el  modelo. 
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1.  Cambia  tu  modelo  (en  models. py) . 

2.  Ejecuta  python  manage.py  makemigrations  para  crear  las  migraciones  para 
esos  cambios. 

3.  Ejecuta  python  manage.py  migrate  para  aplicar  esos  cambios  a la  base  de 
datos. 

La  razon  de  usar  comandos  separados,  para  hacer  y aplicar  migraciones  consiste 
en  guardar  las  migraciones  en  un  sistema  de  control  de  versiones  y enviarlas  con  la 
aplicacion,  de  esta  forma  el  desarrollo  sera  mas  facil  y tambien  podran  ser  usados  por 
otros  desarrolladores  en  production. 

Si  estas  interesado,  toma  un  momento  para  bucear  en  el  cliente  de  linea  de 
comandos  de  tu  servidor  de  bases  de  datos  y ver  las  tablas  que  creo  Django.  Puedes 
ejecutar  manualmente  el  cliente  de  linea  de  comandos  (ej.:  psql  para  PostgreSQL)  o 
puedes  ejecutar  el  comando  python  manage.py  dbshell,  que  deducira  que  cliente  de 
linea  de  comando  ejecutar,  dependiendo  de  tu  configuration  de  servidor  de  base  de 
datos.  Esto  ultimo  es  casi  siempre  mas  conveniente. 

Con  todo  esto,  si  estas  interesado  en  verificar  la  base  de  datos,  inicia  el  cliente  de  tu 
base  de  datos  y ejecuta  \dt  (PostgreSQL),  SEIOW  TABLES;  (MySQL),  o .schema 
(SQLite)  para  mostrar  las  tablas  que  Django  ha  creado. 

Migraciones 

En  este  punto,  quizas  te  preguntes  jQue  son  las  migraciones?  Las  migraciones 
son  la  forma  en  que  Django  se  encarga  de  guardar  los  cambios  que  realizamos  a los 
modelos  (Agregando  un  campo,  una  tabla  o borrando  un  modelo...  etc.)  en  el 
esquema  de  la  base  de  datos.  Estan  disenadas  para  funcionar  en  su  mayor  parte  de 
forma  automatica,  utilizan  una  version  de  control  para  almacenar  los  cambios 
realizados  a los  modelos  y son  guardadas  en  un  archivo  del  disco  llamado  “migration 
files”,  que  no  es  otra  cosa  mas  que  archivos  Python,  por  lo  que  estan  disponibles  en 
cualquier  momento. 

Las  migraciones  estan  creadas  para  funcionar  sobre  una  aplicacion  Django, 
podemos  pensar  en  ellas  como  en  una  version  de  control  para  nuestra  base  de  datos. 
Permiten  a Django  y a los  desarrolladores  manejar  el  esquema  de  la  base  de  datos  de 
forma  transparente  y duradera. 

Existen  dos  comandos  para  usar  e interactuar  con  las  migraciones: 

■ makemigrations:  es  responsable  de  crear  nuevas  migraciones  basadas  en  los 
cambios  aplicados  a nuestros  modelos. 

■ migrate:  responsable  de  aplicar  las  migraciones  y los  cambios  al  esquema  de 
la  base  de  datos. 

Estos  dos  comandos  se  usan  de  forma  interactiva,  primero  se  crean  o graban  las 
migraciones,  despues  se  aplican: 

python  manage.py  makemigrations 

python  manage.py  migrate 

Las  migraciones  se  derivan  enteramente  de  los  archivos  de  los  modelos  y son 
esencialmente  registros,  que  se  guardan  como  historia,  para  que  Django  (o  cualquier 
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desarrollador)  pueda  consultarlos,  cuando  necesita  actualizar  el  esquema  de  la  base 
de  datos  para  que  los  modelos  coincidan  con  los  modelos  actuales. 


Acceso  basico  a datos 

Una  vez  que  has  creado  un  modelo,  Django  provee  automaticamente  una  API  Python 
de  alto  nivel  para  trabajar  con  estos  modelos.  Prueba  ejecutando  el  comando:  python 
manage. py  shell  y escribiendo  lo  siguiente: 

»>  from  biblioteca.models  import  Editor 

»>  pi  = Editor(nombre='Addison-Wesley',  domicilio='75  Arlington  Street', 
ciudad- Boston',  estado- MA',  pais- U.S.A.', 
website='http://www.apress.com/') 

»>  pl.save() 

»>  p2  = Editor(nombre="0'Reilly",  domicilio- 10  Fawcett  St.', 
ciudad- Cambridge',  estado='MA',  pais='U.S.A  , 
website='http://www.oreilly.com/') 

»>  p2.save() 

»>  Lista_Editores  = Editor. objects. all() 

»>  Lista_Editores 

[<Editor:  Editor  object>,  <Editor:  Editor  object>] 

Estas  pocas  llneas  logran  bastantes  resultados.  Estos  son  los  puntos  sobresalientes: 

■ Para  crear  un  objeto,  solo  importa  la  clase  del  modelo  apropiado  y crea  una 
instancia  pasandole  valores  para  cada  campo. 

■ Para  guardar  el  objeto  en  la  base  de  datos,  llama  el  metodo  save()  del  objeto. 
Detras  de  la  escena,  Django  ejecuta  aqui  una  sentencia  SQL  INSERT. 

■ Para  recuperar  objetos  de  la  base  de  datos,  usa  el  atributo  Editor. objects. 
Busca  una  lista  de  todos  los  objetos  Editor  en  la  base  de  datos  con  la  sentencia 
Editor.objects.all().  Detras  de  escenas,  Django  ejecuta  aqui  una  sentencia  SQL 
SELECT. 


Nota:  Siempre  guarda  tus  objetos  con  save(): 

Una  cosa  que  vale  la  pena  mencionar  y que  no  fue  muy  clara  en  el  ejemplo 
anterior,  es  que  cuando  creamos  un  objeto  usando  la  API  (la  capa  de  modelo  de 
Django),  es  que  los  objetos  no  se  guardan  en  la  base  de  datos,  hasta  que  se  llama  al 
metodo  save()  explicitamente: 

»>pl  = Editor(...)#  iEn  este  punto,  pi  no  ha  sido  guardado  en  la  base  de  datos! 
>»pl.save()#  Ahora,  si. 


Si  quieres  crear  y guardar  un  objeto  en  la  base  de  datos,  en  un  simple  paso  usa  el 
metodo  objects. create!)  ■ Este  ejemplo,  es  equivalente  al  ejemplo  anterior: 

»>  pi  = Editor. objects. create(nombre- Apress', 
domicilio- 2855  Telegraph  Avenue', 
ciudad- Berkeley',  estado-CA',  pais- U.S.A.', 
website='http://www.apress.com/') 
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»>  p2  = Editor. objects. create(nombre- 'O'Reilly", 
domicilio='10  Fawcett  St. , ciudad='Cambridge', 
estado- MA’,  pais='U.S.A.', 
website='http://www.oreilly.com/') 

»>  Lista_Editores  = Editor. objects. all() 

»>  Lista_Editores 

Naturalmente,  puedes  hacer  mucho  mas  con  la  API  de  base  de  datos  de  Django  - 
pero  primero,  arreglemos  una  pequena  incomodidad-. 

Agrega  cadenas  de  representacion  a tus  modelos 

Cuando  imprimimos  la  lista  de  editores,  todo  lo  que  obtuvimos  fue  una  salida  poco 
util,  que  hacia  dificil  distinguir  los  objetos  Editor: 

[<Editor:  Editor  object>,  <Editor:  Editor  object>] 

Podemos  arreglar  esto  facilmente  agregando  un  metodo  llamado str (),  si  estas 

usando  python3  o un  metodo  Unicode (),  si  estas  usando  Python2,  a nuestro 

objeto  Editor.  Un  metodo str ()  le  dice  a Python  como  mostrar  la  representacion 

“string”  de  un  objeto  en  Unicode.  Puedes  ver  esto  en  action  agregando  un  metodo 
str ()  a tus  tres  modelos: 


biblioteca/models . py 


from  django.db  import  models 

class  Editor(models. Model): 

nombre  = models.  CharField(max_length=30) 
domicilio  = models.  CharField(max_length=50) 
ciudad  = models.  CharField(max_length=60) 
estado  = models.  CharField(max_length=30) 
pais  = models.  CharField(max_length=50) 
website  = models. URLFieldQ 

def str (self):  # Unicode en  Python  2 

return  self. nombre 

class  Autor(models. Model): 

nombre  = models.  CharField(max_length=30) 
apellidos  = models.  CharField(max_length=40) 
email  = models. EmailField() 

def str (self):  # Unicode en  Python  2 

return  '%s  %s'  % (self. nombre,  .apellidos) 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 
editor  = models. ForeignKey(Editor) 
fecha_publicacion  = models. DateField() 
portada  = models. lmageField(upload_to='portadas') 

def str (self):  # Unicode en  Python  2 

return  self.titulo 


91 


CAPITULO  5 MODELOS 


Como  puedes  ver,  un  metodo str ()  puede  hacer  lo  que  sea  que  necesite  hacer 

para  devolver  una  representation  textual.  Aqui,  los  metodos str ()  de  Editor  y 

Libro  devuelven  simplemente  el  nombre  y titulo  del  objeto  respectivamente,  pero  el 

str ()  del  Autor  es  un  poco  mas  complejo  - junta  los  campos  nombre  y apellidos. 

El  unico  requerimiento  para str ()  es  que  devuelva  una  cadena.  Si str ()  no 

devuelve  una  cadena  si  retorna,  digamos,  un  entero  - entonces  Python  generara  un 
error,  como  TypeError  con  un  mensaje  como  " str returned  non-string". 


<j,Que  son  los  objetos  Unicode?  Puedes  pensar  en  objetos  Unicode,  como  en 
cadenas  que  pueden  manejar  mas  de  un  millon  de  distintos  tipos  de  caracteres,  que 
van  desde  versiones  de  caracteres  latinos,  no  latinos,  citas  en  chino,  y simbolos 
“obscuros”. 

Las  cadenas  normales  en  Python2,  son  codificadas usando  un  tipo  de  codificacion 
especial,  tal  como:  ASCII,  ISO-8859- 1 o UTF-8  (En  python3  todas  las  cadenas  son 
Unicode).  Si  almacenas  caracteres  sencillos  (cualquier  cosa  entre  el  estandar  128 
ASCII,  tal  como  letras  de  la  A-Z  y numeros  del  0-9)  en  cadenas  normales  de  Python2 
no  debes  de  perder  de  vista  la  codificacion  que  estas  usando,  para  que  los  caracteres 
puedan  ser  mostrados  cuando  sean  imprimidos.  Los  problemas  ocurren  cuando 
guardamos  los  datos  en  un  tipo  de  codificacion  y los  combinamos  con  diferentes 
codificaciones,  si  tratamos  de  mostrarlos  en  nuestras  aplicaciones,  estas  asumen  un 
cierto  tipo  de  codificacion.  Alguna  vez  has  visto  paginas  Web  o e-mails  que  muestran 
caracteres  como  ”???  ??????”  en  lugar  de  palabras;  esto  generalmente  sugiere  un 
problema  de  codificacion. 

Los  objetos  Unicode  no  tienen  una  codificacion,  su  uso  es  consistente,  son  un 
conjunto  universal  de  caracteres  llamado  “Unicode.”  Cuando  se  utilizan  objetos 
Unicode  en  Python,  puedes  mezclarlos  y acoplarlos  con  seguridad,  si  tener  que 
preocupare  sobre  problema  de  codificacion. 

Django  utiliza  objetos  Unicode  en  todo  el  framework.  Los  objetos  de  los  modelos 
son  recuperados  como  objetos  Unicode,  las  vistas  interactuan  con  datos  Unicode,  y 
las  plantillas  son  renderizadas  como  Unicode.  Generalmente  no  debes  preocuparte 
por  esto,  solo  asegurate  que  tus  codificaciones  sean  correctas;  y las  cosas  trabajaran 
bien. 

Hemos  tratado  este  tema  muy  a la  ligera,  sin  embargo  si  quieres  aprender  mas  sobre 
objetos  Unicode,  un  buen  lugar  para  empezar  es: 

(5)  http://www.joelonsoftware.com/articles/Unicode.html 


Para  que  los  cambios  sean  efectivos,  sal  del  shell  Python  (usando  exit())  y entra  de 
nuevo  con  python  manage. py  shell.  (Esta  es  la  manera  mas  simple  de  hacer  que  los 
cambios  en  el  codigo  tengan  efecto.)  Ahora  la  lista  de  objetos  Editor  es  mas  facil  de 
entender: 

»>  from  biblioteca.models  import  Editor 
»>  ListaEditores  = Editor. objects. all() 

»>  ListaEditores 

[<Editor:  Addison-Wesley>,  <Editor:  0'Reilly>] 

Asegurate  de  que  cada  modelo  que  definas  tenga  un  metodo str ()  - no  solo  por 

tu  propia  conveniencia  cuando  usas  el  interprete  interactivo,  sino  tambien  porque 

Django  usa  la  salida  de str ()  en  muchos  otros  lugares  cuando  necesita  mostrar 

objetos. 
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Metodos str o Unicode ? 


En  Python  3,  es  facil,  solo  utiliza str (). 

En  Python  2,  es  necesario  definir  metodos Unicode ()  para  que  los  valores  que 

retornen  sean  Unicode.  Los  modelos  de  Django  usan  por  default  str 0,  este 

metodo  llama  a Unicode ()  y convierte  el  resultado  a UTF-8  bytestring.  Esto 

significa  que  Unicode  (p)  retornara  como  cadena  Unicode  y str  (p)  devolvera  una 
cadena  normal,  con  los  caracteres  codificados  como  UTF-8.  Python  hace  lo  contrario: 

toma  un  objeto  que  tiene Unicode y llama  a un  metodo str e interpreta  el 

resultado  como  una  cadena  ASCII  bytestring.  Esta  diferencia  puede  crear  confusion. 

Si  todo  esto  no  tiene  sentido  para  ti,  solo  usa  metodos  str  en  Python  3 y todo 
funcionara  bien. 

Finalmente,  observa  como  el  metodo str ()  es  un  buen  ejemplo  para  agregar 

comportamiento  a los  modelos.  Un  modelo  Django  describe  mas  que  la 
configuration  de  la  tabla  de  la  base  de  datos;  tambien  describe  toda  funcionalidad 

que  el  objeto  sepa  hacer. str ()  es  un  ejemplo  de  esa  funcionalidad  - un  modelo 

sabe  como  mostrarse. 

Insertar  y actualizar  datos 

Ya  has  visto  como  se  hace:  para  insertar  una  fila  en  tu  base  de  datos,  primero  crea 
una  instancia  de  tu  modelo  usando  argumentos  por  nombre,  asi: 

»>  p = Editor(nombre- Apress', 

domicilio- 2855  Telegraph  Ave  , 
ciudad- Berkeley', 
estado- CA', 

...  pais- U.S.A.', 

website- http://www.apress.com/') 

Este  acto  de  instanciar  una  clase  modelo  no  toca  la  base  de  datos. 

Para  guardar  el  registro  en  la  base  de  datos  (esto  es,  para  realizar  la  sentencia  SQL 
INSERT),  llama  al  metodo  save()  del  objeto: 

»>  p.saveQ 

En  SQL,  esto  puede  ser  traducido  directamente  en  lo  siguiente: 

INSERT  INTO  biblioteca_Editor 

(nombre,  domicilio,  ciudad,  estado,  pais,  website) 

VALUES 

('Apress',  '2855  Telegraph  Ave.',  'Berkeley',  'CA',  'U.S.A.',  'http://www.apress.com/'); 

Como  el  modelo  Editor  usa  una  clave  primaria  autoincremental  id,  la  llamada 
inicial  a save()  hace  una  cosa  mas:  calcula  el  valor  de  la  clave  primaria  para  el  registro 
y lo  establece  como  el  valor  del  atributo  id  de  la  instancia: 

»>  p.id 

3 # esto  es  diferente,  segun  tus  datos 

Las  subsecuentes  llamadas  a save()  guardaran  el  registro  en  su  lugar,  sin  crear  un 
nuevo  registro  (es  decir,  ejecutaran  una  sentencia  SQL  UPDATE  en  lugar  de  un 
INSERT): 
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>»  p.nombre  = 'Apress  Publishing' 

»>  p.save() 

La  sentencia  save()  del  parrafo  anterior  resulta  aproximadamente  en  la  sentencia 
SQL  siguiente: 

UPDATE  biblioteca_Editor  SET 
nombre  = 'Apress  Publishing', 
domicilio  = '2855  Telegraph  Ave.', 
ciudad  = 'Berkeley', 
estado  = 'CA', 
pais  = 'U.S.A.', 

website  = 'http://www.apress.com' 

WHERE  id  = 3; 

Ahora,  observa  como  todoslos  campos  han  sido  actualizados,  no  solamente  el  que 
habiamos  cambiado.  Dependiendo  de  tu  aplicacion,  esto  puede  causar  provocar  una 
condition.  Consulta  como  “Actualizar  multiples  objetos  en  una  sola  declaration” 
mas  adelante,  para  ejecutar  una  consulta  (ligeramente  dife rente). 

UPDATE  biblioteca_editor  SET 
nombre  = 'Apress  Publishing' 

WHERE  id=3; 


Seleccionar  objetos 

Conocer  como  crear  y actualizar  datos  en  una  base  de  datos  es  esencial,  pero  hay 
ocasiones  en  que  una  aplicacion  web  necesita  realizar  consultas  para  examinar  los 
objetos  que  se  han  creado. 

Ya  hemos  visto  una  forma  de  examinar  todoslos  datos  de  un  determinado  modelo: 
>»  Editor. objects. all() 

[<Editor:  Addison-Wesley>,  <Editor:  0'Reilly>,  <Editor:  Apress  Publishing>] 

Eso  se  traslada  a esto;  en  SQL: 

SELECT 

id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  book_Editor; 

Nota  que  Django  no  usa  SELECT  * cuando  busca  datos  y en  cambio  lista  todos  los 
campos  explicitamente.  Esto  es  una  decision  de  diseno:  en  determinadas 
circunstancias  SELECT  * puede  ser  lento,  y (mas  importante)  listar  los  campos  sigue 
el  principio  del  Zen  de  Python:  “Explicito  es  mejor  que  implicito”.  Para  saber  mas 
sobre  el  Zen  de  Python,  intenta  escribiendo  import  this  en  el  prompt  de  Python. 
Echemos  un  vistazo  a cada  parte  de  esta  linea  Editor.objects.all(): 

■ En  primer  lugar,  tenemos  nuestro  modelo  definido,  Editor.  Aqui  no  hay  nada 
extrano:  cuando  quieras  buscar  datos,  usa  el  modelo  para  esto. 
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■ Luego,  tenemos  objects.  Tecnicamente,  esto  es  un  administrador  (manager). 
Los  administradores  son  discutidos  en  el  Capitulo  10.  Por  ahora,  todo  lo  que 
necesitas  saber  es  que  los  administradores  se  encargan  de  realizar  todas  las 
operaciones  a “nivel  de  tablas”  sobre  los  datos  incluidos,  y lo  mas  importante: 

las  consultas. 

■ Todos  los  modelos  automaticamente  obtienen  un  administrador  objects; 
debes  usar  el  mismo  cada  vez  que  quieras  consultar  sobre  una  instancia  del 
modelo. 

■ Finalmente,  tenemos  all().  Este  es  un  metodo  del  administrador  objects  que 
retorna  todas  las  filas  de  la  base  de  datos.  Aunque  este  objeto  se  parece  a una 
lista,  es  realmente  un  QuerySet  - un  objeto  que  representa  algun  conjunto  de 
filas  de  la  base  de  datos.  El  Apendice  C describe  QuerySets  en  detalle.  Para  el 
resto  de  este  capitulo,  solo  trataremos  estos  como  listas  emuladas. 

Cualquier  busqueda  en  base  de  datos  va  a seguir  esta  pauta  general  - llamaremos 
metodos  del  administrador  adjunto  al  modelo  en  el  cual  queremos  hacer  nuestra 
consulta. 


Filtrar  datos 

Aunque  obtener  todos  los  objetos  es  algo  que  ciertamente  tiene  su  utilidad,  la 
mayoria  de  las  veces  lo  que  vamos  a necesitar  es  manejarnos  solo  un  subconjunto  de 
los  datos.  Para  ello  usaremos  el  metodo  filter (): 

»>Editor. objects. filter(nombre="Apress  Publishing") 

[<Editor:  Apress  Publishing>] 

filter  ()  toma  argumentos  clave  que  son  traducidos  en  las  clausulas  SQL  WHERE 
apropiadas.  El  ejemplo  anterior  seria  traducido  en  algo  como: 

SELECT 

id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  biblioteca_Editor 
WHERE  nombre  = 'Apress  Publishing'; 

Puedes  pasarle  a filter()  multiples  argumentos,  para  reducir  las  cosas  aun  mas: 

»>Editor. objects. filter(ciudad="Berkeley",  estado="CA") 

[<Editor:  Apress  Publishing>] 

Estos  multiples  argumentos  son  traducidos  a clausulas  SQL  AND.  Por  lo  tanto  el 
ejemplo  en  el  fragmento  de  codigo  se  traduce  a lo  siguiente: 

SELECT 

id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  biblioteca_Editor 
WHERE  ciudad  = 'U.S.A.'  AND  estado  = 'CA'; 

Observa  que  por  omision  la  busqueda  usa  el  operador  SQL  = para  realizar 
busquedas  exactas.  Existen  tambien  otros  tipos  de  busquedas: 

»>  Editor. objects. filter(nombre contains-'press") 
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[<Editor:  Apress  Publishing>] 

Nota  el  doble  guion  bajo  entre  nombre  y contains.  Del  mismo  modo  que  Python, 
Django  usa  el  doble  guion  bajo  para  indicar  que  algo  “magico”  esta  sucediendo  - 
aqul  la  parte contains  es  traducida  por  Django  en  una  sentencia  SQL  LIKE: 

SELECT 

id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  biblioteca_Editor 
WHERE  nombre  LIKE  '%press%'; 

Hay  disponibles  varios  tipos  de  busqueda,  incluyendo  icontains  (LIKE  no  es 
sensible  a diferencias  de  mayusculas/minusculas),  startswith  y endswith,  y range 
(consultas  SQL  BETWEEN).  El  Apendice  C describe  en  detalle  todos  estos  tipos  de 
busqueda. 

Obtener  objetos  individuates 

El  ejemplo  anterior  usa  el  metodo  filter()  que  retorna  un  QuerySet  el  cual  es  tratado 
como  una  lista,  sin  embargo  en  ocasiones  desearas  obtener  un  unico  objeto.  Para 
esto  existe  el  metodo  get () : 

»>  Editor. objects. get(nombre="Apress  Publishing") 

<Editor:  Apress  Publishing> 

En  lugar  de  una  lista  (o  mas  bien,  un  QuerySet),  este  metodo  retorna  un  objeto 
individual.  Debido  a eso,  una  consulta  cuyo  resultado  contenga  multiples  objetos 
causara  una  exception: 

»>  Editor. objects. get(pais="U.S. A.") 

Traceback  (most  recent  call  last): 

MultipleObjectsReturned:  get()  returned  more  than  one  Editor  -- 

it  returned  2!  Lookup  parameters  were  {'pais':  ’U.S.A.'} 

Por  lo  que  una  consulta,  que  no  retorne  un  objeto  tambien  causara  una  exception: 

»>  Editor. objects. get(nombre="Pinguino") 

Traceback  (most  recent  call  last): 

DoesNotExist:  Editor  matching  query  does  not  exist. 


La  exception  DoesNotExist  es  un  atributo  del  modelo  de  la  clase 
Editor.DoesNotExist.  Si  quieres  atrapar  las  excepciones  en  tus  aplicaciones,  puedes 
hacerlo  de  la  siguiente  forma: 

try: 

p = Editor. objects. get(nombre='Apress') 
except  Editor.DoesNotExist: 

print  ("Apress  no  esta  en  la  base  de  datos. ') 
else: 

print  ("Apress  esta  en  la  base  de  datos.  ') 
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Ordenar  datos 

A medida  que  juegas  con  los  ejemplos  anteriores,  podrias  descubrir  que  los  objetos 
son  devueltos  en  lo  que  parece  ser  un  orden  aleatorio.  No  estas  imaginandote  cosas, 
hasta  ahora  no  le  hemos  indicado  a la  base  de  datos  como  ordenar  los  resultados,  de 
manera  que  simplemente  estamos  recibiendo  datos  con  algun  orden  arbitrario 
seleccionado  por  la  base  de  datos. 

Eso  es,  obviamente,  un  poco  ingenuo.  No  quisieramos  que  una  pagina  Web  que 
muestra  una  lista  de  editores  estuviera  ordenada  aleatoriamente.  As!  que,  en  la 
practica,  probablemente  querremos  usar  orderJbyO  para  reordenar  nuestros  datos 
en  listas  mas  utiles: 

»>  Editor. objects. order_by("nombre") 

[<Editor:  Addison-Wesley>,  <Editor:  Apress  Publishing?-,  <Editor:  0'Reilly>] 

Esto  no  se  ve  muy  diferente  del  ejemplo  del  metodo  all()  anterior,  pero  el  SQL 
incluye  ahora  un  ordenamiento  especifico: 

SELECT 

id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  biblioteca_Editor 
ORDER  BY  nombre; 

Podemos  ordenar  por  cualquier  campo  que  deseemos: 

»>  Editor. objects. order_by("domicilio") 

[<Editor:  0’Reilly>,  <Editor:  Apress  Publishing>,  <Editor:  Addison-Wesley>] 

»>  Editor. objects. order_by("estado") 

[<Editor:  Apress  Publishing>,  <Editor:  Addison-Wesley>,  <Editor:  0'Reilly>] 

Para  ordenar  por  multiples  campos  (donde  el  segundo  campo  es  usado  para  quitar 
las  ambigiiedades  en  el  orden,  en  casos  donde  el  nombre  sea  el  mismo),  puedes  usar 
multiples  argumentos: 

»>  Editor. objects. order_by("estado",  "domicilio") 

[<Editor:  Apress  Publishing?-,  <Editor:  O'Reilly?-,  <Editor:  Addison-Wesley>] 

Tambien  podemos  especificar  un  ordenamiento  inverso  antecediendo  al  nombre 
del  campo  un  prefijo  - (el  simbolo  menos): 

»>  Editor. objects. order_by("-nombre") 

[<Editor:  0'Reilly>,  <Editor:  Apress  Publishing>,  <Editor:  Addison-Wesley>] 


Aunque  esta  flexibilidad  es  util,  usar  order_by()  todo  el  tiempo  puede  ser 
demasiado  repetitivo.  La  mayor  parte  del  tiempo  tendras  un  campo  en  particular  por 
el  que  usualmente  desearas  ordenar  tus  datos.  Es  esos  casos  Django  te  permite 
anexar  al  modelo  un  ordenamiento  por  omision,  usando  una  clase  interna  Meta: 
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class  Editor(models. Model): 

nombre  = models.  CharField(max_length=30) 
domicilio  = models.  CharField(max_length=50) 
ciudad  = models.  CharField(max_length=60) 
estado  = models.  CharField(max_length=30) 
pais  = models.  CharField(max_length=50) 
website  = models. URLFieldQ 

class  Meta: 

ordering  = ["nombre"] 

def str (self): 

return  self. nombre 


Hemos  introducido  un  nuevo  concepto:  class  Meta  (Una  clase  Meta  interna),  esta 
clase  esta  embebida  en  la  definition  de  la  clase  Editor"  (identada  dentro  de  la  clase 
"Editor).  Podemos  usar  una  clase  Meta  en  cualquier  modelo  para  especificar  varias 
opciones  especificas  en  un  modelo.  Examina  el  Apendice  B para  conocer  las  opciones 
que  puede  poner  bajo  Meta.  En  el  ejemplo  anterior  ordering  = ["nombre"]  le  indica  a 
Django  que  a menos  que  se  proporcione  un  ordenamiento  mediante  order_by(), 
todos  los  editores  deberan  ser  ordenados  por  su  nombre. 

Django  usa  esta  class  Meta  interna  como  un  lugar  en  el  cual  se  pueden  especificar 
metadatas  adicionales  acerca  de  un  modelo.  Es  completamente  opcional,  pero  puede 
realizar  algunas  cosas  muy  utiles,  como  usar  el  nombre  en  plural  de  la  tabla  usando 
verbose_name_plural. 


Encadenar  biisquedas 

Idas  vista  como  puedes  filtrar  datos  y has  vista  como  ordenarlos.  En  ocasiones,  por 
supuesto,  vas  a querer  realizar  ambas  cosas.  En  esos  casos  simplemente  “encadena” 
las  busquedas  entre  si: 

»>  Editor. objects. filter(pais="U.S.  A."). order_by("-nombre') 

[<Editor:  0'Reilly>,  <Editor:  Apress  Publishing>,  <Editor:  Addison-Wesley>] 

Como  podrias  esperar,  esto  se  traduce  a una  consulta  SQL  conteniendo  tanto  un 
WE1ERE  como  un  ORDER  BY: 

SELECT  id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  biblioteca_Editor 
WHERE  country  = 'U.S.A' 

ORDER  BY  nombre  DESC; 

Puedes  encadenar  consultas  en  forma  consecutiva  tantas  veces  como  desees.  No 
existe  un  limite  para  esto. 

Rebanar  datos 

Otra  necesidad  comun  es  buscar  solo  un  mimero  fijo  de  filas.  Imagina  que  tienes 
miles  de  editores  en  tu  base  de  datos,  pero  quieres  mostrar  solo  el  primero.  Puedes 
hacer  eso  usando  la  sintaxis  estandar  de  Python  para  el  rebanado  de  listas: 
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»>  Editor. objects. all()[0] 

<Editor:  Addison-Wesley> 

Esto  se  traduce,  someramente,  a: 

SELECT 

id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  biblioteca_editor 
ORDER  BY  nombre 

LIMIT  1; 

Similarmente,  puedes  recuperar  un  subconjunto  especifico  de  datos  usando  la 
sintaxis  de  Python  y rebanando  un  rango  de  datos: 

»>  Editor. objects. order_by('nombre')[0:2] 

Esto  devuelve  dos  objetos,  lo  que  seria  equivalente  en  SQL  a: 

SELECT  id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  biblioteca_editor 
ORDER  BY  nombre 
OFFSET  0 LIMIT  2; 

Observa  que  el  rebanado  negativo  noe sta  soportado: 

»>  Editor. objects. order_by('nombre')[-l] 

Traceback  (most  recent  call  last): 

AssertionError:  Negative  indexing  is  not  supported. 

Sin  embargo  es  facil  darle  la  vuelta  a esto.  Cambia  la  declaration  order_by()  asi: 

»>  Editor. objects. order_by( -nombre  )[0] 


Actualizar  multiples  campos  en  una  sola  declaracion 


Ya  vimos  en  la  section  “ Insertando  y actualizando  datos"  que  el  metodo  save() 
actualiza  todas  las  columnas  de  una  fila.  Sin  embargo,  dependiendo  de  nuestra 
aplicacion,  podemos  actualizar  unicamente  un  subconjunto  de  columnas. 

Por  ejemplo,  digamos  que  queremos  actualizar  el  nombre  Apress  de  la  tabla 
Editor,  para  cambiarle  el  nombre  de  'Apress'  a 'Apress  Publishing'.  Usando  el  metodo 
save(),  podemos  hacerlo  asi: 

»>  p = Editor. objects. get(nombre='Apress') 

»>  p. nombre  = 'Apress  Publishing' 

»>  p.save() 

Esto  se  traduce,  aproximadamente  en  la  siguiente  declaracion  SQL: 

SELECT  id,  nombre,  domicilio,  ciudad,  estado,  pais,  website 
FROM  bibliotecajibro 
WHERE  nombre  = 'Apress'; 
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UPDATE  biblioteca_editor  SET 
nombre  = 'Apress  Publishing', 
domicilio  = '2855  Telegraph  Ave.', 
ciudad  = 'Berkeley', 
estado  = 'CA', 
pais  = 'U.S.A.', 

website  = 'http://www.apress.com' 

WHERE  id  = 3; 

(Observa  que  el  ejemplo  asume  que  un  Editor  Apress,  tiene  un  ID  = 3 ) 

Puedes  ver  en  este  ejemplo  que  el  metodo  save/),  guarda  lodos  los  valores  de  las 
columnas,  no  solo  la  columna  nombre.  Si  estas  en  un  entorno  donde  otras  columnas 
de  la  base  de  datos  puedan  cambiar  debido  a otro  proceso,  es  mas  elegante  cambiar 
unicamente  una  columna  que  se  necesita  cambiar.  Para  esto  usa  el  metodo  update/) 
cuando  consultes  objetos.  Por  ejemplo: 

»>  Editor. objects. filter/  =l).update(nombre- Apress  Publishing') 

La  traduccion  a SQL  es  mucho  mas  eficiente  y no  hay  probabilidades  de  errores: 

UPDATE  biblioteca_editor 
SET  name  = 'Apress  Publishing' 

WHERE  id  = 1; 

El  metodo  update/)  trabaja  con  cualquier  consulta,  lo  cual  quiere  decir  que 
puedes  editar  multiples  registros  a la  vez.  Esta  es  la  forma  en  podemos  cambiar 
ciudad  de  'U.S.A.'  a USA  en  cada  registro  Editor: 


»>  Editor. objects. all/). update/ciudad- USA') 

2 


El  metodo  update/)  retorna  un  valor  - un  entero  que  representa  las  veces  que  un 
registro  ha  cambiado.  En  el  ejemplo  anterior  obtuvimos  2. 


Borrar  objetos 


Para  eliminar  objetos,  simplemente  llama  al  metodo  delete/)  de  tu  objeto: 

»>  p = Editor. objects. get/nombre-'Addison-Wesley") 

»>  p. delete/) 

»>  Editor. objects. all/) 

[<Editor:  Apress  Publishing>,  <Editor:  0'Reilly>] 

Tambien  puedes  borrar  objetos  al  por  mayor  llamando  al  metodo  delete/)  en  el 
resultado  de  cualquier  consulta.  Esto  es  similar  a el  metodo  update/)  que  mostramos 
en  la  section  anterior: 

»>  Editor. objects. filter/ciudad- USA'). delete/) 

»>  Editor. objects. all/). delete/) 

»>  Editor. objects. all/) 
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D 


Los  borrados  son  deGnitivos,  asi  que,  ;se  cuidadoso!  Como  medida  de  precaution, 
Django  evita  que  puedas  borrar  los  datos  de  una  tabla  en  particular  directamente,  a 
menos  que  explicitamente  asi  lo  requieras,  usa  el  metodo  all () , si  quieres  borrar  toda 
la  tabla. 

Por  ejemplo  esto  no  trabaja: 

»>  Editor. objects. delete() 

Traceback  (most  recent  call  last): 

File  "<console>  , line  1,  in  <module> 

Attribute  Error:  'Manager'  object  has  no  attribute  'delete' 

Pero  si  agregas  un  metodo  all 0 , funcionara  bien: 

»>  Editor. objects. all().delete() 

Si  solo  quieres  borrar  un  subconjunto  de  datos,  no  necesitas  incluir  el  metodo 
all  () : 

»>  Editor. objects. filter(ciudad='USA').delete() 


^Que  sigue? 

Despues  de  leer  este  capitulo,  haz  adquirido  el  conocimiento  suficiente  sobre  los 
modelos  Django,  esto  te  permitira  escribir  aplicaciones  basicas  usando  una  base  de 
datos.  En  el  capitulo  10  encontraras  mas  information  sobre  un  uso  mas  avanzado  de 
la  capa  de  modelos  de  Django. 

Una  vez  que  has  deflnido  tus  modelos,  el  siguiente  paso  es  ingresar  datos  a la  base 
de  datos.  Podrias  tener  datos  legados,  en  cuyo  caso  el  capitulo  18ie  aconsejara  acerca 
de  como  integrar  bases  de  datos  heredadas.  Podrias  delegar  en  el  usuario  del  sitio  la 
provision  de  los  datos,  en  cuyo  caso  el  capitulo  7 te  ensenara  como  procesar  datos 
enviados  por  los  usuarios  mediante  formularios. 

Pero  en  algunos  casos,  tu  o tu  equipo  podrian  necesitar  ingresar  datos  en  forma 
manual,  en  cuyo  caso  serfa  de  ayuda  el  disponer  de  una  interfaz  basada  en  Web  para 
el  ingreso  y el  manejo  de  los  datos.  El  proximo  capitulo  esta  dedicado  a la  interfaz  de 
administration  de  Django,  la  cual  existe  precisamente  por  esa  razon. 
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El  sitio  de  administration 


P ara  un  cierto  tipo  de  sitios  Web,  una  interfaz  de  administracion  es  una  parte 
esencial  de  su  infraestructura.  Ya  que  se  trata  de  una  interfaz  basada  en  HTML, 
limitada  a los  administradores  autorizados,  que  permite  agregar,  editar  y eliminar  el 
contenido  del  sitio. 

La  interfaz  que  usas  para  escribir  en  tu  blog,  el  sitio  privado  que  los  editores  usan 
para  moderar  los  comentarios  de  sus  lectores,  la  herramienta  que  tus  clientes  utilizan 
para  actualizar  los  comunicados  de  prensa  en  la  Web,  que  construiste  para  ellos  - 
todos  ellos  son  ejemplos  de  interfaces  de  administracion. 

Sin  embargo,  existe  un  problema  con  las  interfaces  de  administracion:  es  aburrido 
construirlas.  El  desarrollo  Web  es  divertido  cuando  estas  desarrollando 
funcionalidades  del  lado  publico  del  sitio,  pero  construir  interfaces  de 
administracion  es  siempre  lo  mismo.  Tienes  que  autentificar  usuarios,  mostrar  y 
manipular  formularios,  validar  las  entradas  y demas  tareas.  Es  aburrido  y repetitivo. 

iCual  es  la  solucion  de  Django  para  estas  tareas  aburridas  y repetitivas?  Las  hace 
todas  por  ti  - en  solo  un  par  de  lineas  de  codigo,  ni  mas  ni  menos.  Con  Django, 
construir  interfaces  de  administracion  es  un  problema  resuelto. 

Este  capitulo  trata  sobre  la  interfaz  de  administracion  automatica  de  Django.  Esta 
caracteristica  funciona  leyendo  las  metadatos  en  tus  modelos  para  brindar  una 
interfaz  potente  y lista  para  production  que  los  administradores  del  sitio  podran  usar 
inmediatamente.  En  este  capitulo  discutimos  como  activar,  usar  y personalizar  esta 
utilidad. 

Recomendamos  leer  este  capitulo,  inclusive  si  no  te  propones  usar  el  sitio  de 
administracion,  porque  introduciremos  algunos  conceptos  generales,  que  se  pueden 
aplicar  a Django  en  general,  sin  importar  si  usas  la  interfaz  administrativa  o no. 

El  paquete  django.contrib 

La  interfaz  de  administracion  de  Django  es  solo  una  parte  de  la  gran  suite  de 
funcionalidades  llamado  django.contrib,  la  parte  del  codigo  de  Django  que  contiene 
diversos  accesorios  utiles  del  framework  base.  Puedes  pensar  en  django.contrib  como 
el  equivalente  a una  libreria  estandar  de  Python  - opcional,  efectivo  y que 
implementa  muchos  patrones  comunes.  Las  cuales  estas  incrustados  en  Django  y nos 
ayudaran  a no  reinventar  la  rueda  en  nuestras  aplicaciones. 

El  sitio  de  administracion  es  la  primera  parte  de  django.contrib,  que  cubriremos 
en  este  libro;  tecnicamente,  es  llamado  django.contrib. admin.  Algunas  caracteristicas 
mas  que  podemos  mencionar  de  django.contrib,  es  que  incluye  un  sistema  de 
autentificacion  (django.contrib.auth),  ofrece  soporte  para  sesiones  anonimas 
(django.contrib. sessions),  etiquetas  para  desarrolladores  Web, 
(django.contrib.webdesign),  etiquetas  para  darle  un  toque  humano  al  framework 
(django.contrib.humanize) . 
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En  este  capitulo  conoceras  diversas  caracteristicas  de  django.contrib  que  te 
convertiran  en  un  experto  en  Django,  discutiremos  mas  adelante  este  tema,  en  el 
capitulol6.  Por  ahora,  simplemente  ten  en  cuenta  que  este  paquete  contiene  muchos 
agregados  utiles,  y que  django.contrib  es  generalmente  el  lugar  en  donde  se  localizan. 


Activar  la  interfaz  administrativa 

Una  de  las  partes  mas  poderosas  y atractivas  de  Django  es  la  interfaz  administrativa. 
Que  se  encarga  de  leer,  automaticamente  los  metadatos  de  tus  modelos  para  proveer 
una  interfaz  poderosa  y lista  para  production,  para  que  inmediatamente  puedas 
comenzar  a anadirle  contenido  a tu  sitio  Web. 

Sin  embargo  la  interfaz  de  administracion  es  enteramente  opcional,  porque 
unicamente  un  cierto  tipo  de  sitios  necesitan  esta  funcionalidad.  Esto  significa  que  se 
puede  activar  o desactivar  segun  tus  necesidades  especificas. 

En  la  siguiente  parte  discutimos  como  activar,  usar  y personalizar  la  interfaz 
administrativa  de  Django. 

Para  referencia  estos  son  los  requisitos: 

■ Agrega  'django.contrib. admin'  a la  variable  INSTALLED_APPS  de  tu  archivo 
de  conImagenciones.(El  orden  en  INSTALLED_APPS  si  importa,  sin  embargo 
estas  estan  ordenadas  alfabeticamente  para  facilitar  su  lectura,  y Django  las 
carga  conforme  estan  ordenadas,  este  detalle  es  importante  ya  que  si  quieres 
que  django  cargue  primero  tus  plantillas,  necesitas  poner  tu  aplicacion  antes 
que  el  propio  'django.contrib. admin',  para  que  las  use.) 

■ La  interfaz  administrativa  tiene  cuatro  dependencias  (que  dependen  unas  de 
otras),  por  lo  que  asegurate  que  esten  todas  activadas: 

• django. contrib.auth 

• django. contrib.contenttypes 

• django.contrib. messages 

• django.contrib. sessions 

Si  estas  aplicaciones  no  estas  listadas  en  la  variable  INSTALLED_APPS, 
agregalas. 

■ Agrega  django.contrib. messages. context_processors. messages  a 
TEMPLATE_CONTEXT_PROCESSORS  (a  la  variable)  asi  como  tambien  agrega 
django.  contrib.auth.middleware.AuthenticationMiddlewarey 
django.contrib. messages. middleware. MessageMiddleware  a 
MIDDLEWARE_CLASSES.  (Estos  estan  activados  por  omision,  asi  que  solo 
necesitas  hacerlo  manualmente,  si  hiciste  algun  cambio  a la  configuration  o 
los  habias  comentado  previamente). 

■ Determina  que  modelos  de  tus  aplicaciones  seran  editables  en  la  interfaz 
administrativa. 

No  todos  los  modelos  pueden  (o  deberian)  ser  editables  por  los  usuarios 
administradores,  por  lo  que  necesitas  “marcar”  los  modelos  que  deberian 
tener  una  interfaz  de  administracion.  (Anadiendo  una  clase  ModelAdmin  al 
archivo  admin.py.) 
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■ Por  cada  uno  de  los  modelos,  crea  opcionalmente  una  clase  ModelAdmin  en 
el  archivo  admin.py,  que  encapsule  las  funcionalidades  personalizadas  y las 
opciones  especfficas,  para  cada  modelo  en  particular. 

■ Instancia  una  clase  AdminSite  y registra  cada  uno  de  los  modelos  en  la  clase 
ModelAdmin 

■ Apunta  la  instancia  AdminSite  a tu  URLconf. 


Nota:  La  interfaz  administrativa  esta  habilitado  por  omision  en  la  plantilla  de  tu 
proyecto,  si  creaste  tu  proyecto  usando  startproject.  La  cual  incluye  una  URL  y una 
configuracion  para  usar  SQLite  como  base  de  datos.  Por  lo  que  solo  debes 
preocuparte  por  los  requisitos  anteriores,  si  haz  personalizado,  borrado  o 
comentado  el  archivo  de  configuracion  settings.py. 


Una  vez  que  nos  hemos  asegurado  de  tener  todos  los  requisitos  en  orden, 
podemos  llamar  directamente  al  comando  migrate  para  que  se  encargue  de  instalar 
las  tablas,  que  la  interfaz  de  administration  necesita  en  la  base  de  datos. 

python  manage. py  migrate 

Como  se  menciona  en  capitulos  anteriores,  el  comando  migrate  examina  todos  los 
modelos  en  cada  aplicacion  activada,  que  figure  en  tu  variable  de  configuracion 
INSTALLED_APPS,  y verifica  el  esquema  de  la  base  de  datos  para  comprobar  si  las 
tablas  apropiadas  ya  existen,  y las  crea  si  no  existen.  Mostrando  un  mensaje  por  cada 
migration  aplicada. 

La  interfaz  administrativa  instala  4 aplicaciones  y una  de  ellas  es 
django.contrib.auth  el  sitio  de  autorizaciones,  por  lo  que  al  instalarlo  es  necesario 
crear  interactivamente  un  super-usuario,  con  el  siguiente  comando: 

python  manage. py  createsuperuser 

Sigamos  interactivamente  la  salida  del  comando  createsuperuser: 

■ Nos  pedira  un  nombre  de  usuario.  Por  defecto  utilizara  el  nombre  del  sistema. 
Introducimos  el  nombre  de  nuestra  preferencia  y presionamos  de  nuevo 
enter: 

Username  (leave  blank  to  use  'your_username'):  admin 

■ Nos  pedira  tambien  una  direccion  de  correo  electronico:: 

Email  address:  admin@example.com 

■ Finalmente  nos  pedira  una  contrasena.  Por  lo  que  es  necesario  introducir  dos 
veces  la  misma  contrasena  (la  segunda  vez  solo  como  confirmation  de  la 
primera): 

Password:  ********** 

Password  (again):  ********* 

Superuser  created  successfully. 
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El  comando  migrate  toma  todas  las  migraciones  que  se  han  aplicado  al  proyecto 
(ya  que  Django  rastrea  cada  una  de  las  migraciones  aplicadas,  usando  una  tabla 
especial  llamada  django_migrations),  esencialmente  las  ejecuta  de  nuevo  contra  la 
base  de  datos,  sincronizando  los  cambios  hechos  a los  modelos  con  el  esquema  de  la 
base  de  datos. 

Una  vez  creadas  las  tablas,  solo  necesitas  agregar  el  patron  URL  al  archivo  urls.py. 
Si  aun  estas  usando  el  que  fue  creado  por  startproject,  el  patron  de  la  URL  de 
administracion  ya  deberia  estar  ahi,  pero  comentado.  De  cualquier  forma,  el  patron 
URL  debe  terminar  viendose  asi: 


urls .py 


from  django.conf.urls  import  url 
from  django.contrib  import  admin 

urlpatterns  =[ 

url(r'Aadmin/',  include('django.contrib. admin. urls')), 

] 


Eso  es  todo.  Ahora  ejecuta  python  manage.py  runserver  para  iniciar  el  servidor  de 
pruebas.  Veras  algo  como  esto: 

Validating  models... 

0 errors  found. 

Django  version  1.8,  using  settings  ' misitio . settings ' 

Development  server  is  running  at  http : //127 . 0 . 0 . 1 : 8000/ 

Quit  the  server  with  CONTROL-C. 

Ahora  puedes  visitar  la  URL  que  te  brinda  Django,  para  acceder  a la  interfaz 
administrativa,  identifrcarte,  yjugar  unpoco.  (http:// 127.0.0. 1:8000 /admin/) 


Usar  la  interfaz  de  administracion 

La  interfaz  de  administracion  esta  disenada  para  ser  usada  por  usuarios  no  tecnicos, 
y como  tal  deberia  ser  lo  suficientemente  clara  como  para  explicarse  por  si  misma. 
Aun  asi,  se  brindan  algunas  notas  sobre  sus  genialidades  caracteristicas. 

Lo  primero  que  veras  sera  una  pagina  de  identification,  como  la  que  se  muestra  a 
continuation: 


127.0.01:8000/admin/ 


c]  /•  EiS  sfc  d * = 


Administracion  de  Django 


Nombre  de  usuario: 


Contrasena: 


Identifies  rse 


Imagen  6-1.  Pantalla  de  autentificacion  de  Django. 
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Usa  el  nombre  de  usuario  y la  clave  que  configuraste  cuando  agregaste  el 
superusuario  a traves  de  la  terminal.  Una  vez  identificado,  veras  que  puedes 
gestionar  usuarios,  grupos  y permisos  (veremos  mas  sobre  esto  en  breve). 

Una  vez  que  nos  hemos  autentiflcado,  la  primera  cosa  que  veremos  sera  la  pagina 
de  inicio  o “Indice”.  Esta  pagina  contiene  una  lista  de  todos  los  datos  disponibles  que 
pueden  ser  editados  en  la  pagina  del  sitio  de  administracion.  Como  aun  no  hemos 
activado  nuestros  modelos  (Los  activaremos  mas  adelante),  la  lista  de  aplicaciones  es 
escasa,  solo  incluye  Grupos  y Usuarios,  los  cuales  son  agregados  a la  interfaz  por 
omision. 


$ 127t).01:800Q/admin/ v C h ft  = 


Administracion  d©  Django  Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesion 


Administracion  del  sitio 


1 Authentication  and  Authorization 

Acciones  recientes 

Grupos 

♦ Agregar 

/Modificar 

Mis  acciones 

Usuarios 

♦ Agregar 

/Modificar 

Imagen  6-2.  El  Indice  principal  de  la  Administracion  de  Django. 

Cada  tipo  de  datos  en  la  interfaz  administrativa,  contienen  enlaces  para  agregar  y 
modificar  objetos,  que  nos  llevan  a paginas  especificas  a las  que  nos  referiremos 
como  listas  de  cambio  y formularios  de  edicion  de  objetos:  La  lista  de  cambios 
muestra  todos  los  objetos  disponibles  en  la  base  de  datos,  mientras  que  el  formulario 
de  edicion  nos  permite  agregar,  cambiar  o borrar  registros  especificos  de  la  base  de 
datos. 


Otros  lenguajes  en  Django:  Si  tu  lenguaje  natural,  no  es  el  ingles  y si  tu 
navegador  esta  configurado  para  aceptar  otros  lenguajes  ademas  del  ingles,  puedes 
hacer  un  cambio  rapidamente  para  ver  la  interfaz  administrativa  traducida  a tu 
idioma.  Solo  agrega  a la  variable  LANGUAGE_CODE,  que  se  encuentra  en  el  archivo 
de  configuraciones  tu  idioma  nativo.  Django  cuenta  con  traducciones  para  muchos 
lenguajes,  entre  los  que  se  encuentran  al  momento  de  escribir  esto: 

'af , 'Afrikaans',  'ar',  'Arabic',  'az',  'Azerbaijani',  'bg',  'Bulgarian',  'be',  'Belarusian', 
'bn',  'Bengali',  'br',  'Breton',  'bs',  'Bosnian',  'ca',  'Catalan',  'cs',  'Czech',  'ey',  'Welsh', 
'da',  'Danish',  'de',  'German',  'el',  'Greek',  'en',  'English',  'en-au',  'Australian  English', 
'en-gb',  'British  English',  'eo',  'Esperanto',  'es',  'Spanish',  'es-ar',  'Argentinian 
Spanish',  'es-mx',  'Mexican  Spanish',  'es-ni',  'Nicaraguan  Spanish',  'es-ve', 
'Venezuelan  Spanish',  'et',  'Estonian',  'eu',  ’Basque’,  'fa',  'Persian',  'fi',  'Finnish',  'fr', 
'French',  ’fy’,  ’Frisian’,  ’ga’,  ’Irish',  'gl',  'Galician',  'he',  'Hebrew',  'hi',  'Hindi',  'hr', 
'Croatian',  'hu',  'Hungarian',  'ia',  'Interlingua',  'id',  'Indonesian',  'is',  'Icelandic',  'it', 
'Italian',  'ja',  'Japanese',  'ka',  'Georgian',  'kk',  'Kazakh',  'km',  'Khmer',  'kn', 
'Kannada',  'ko',  'Korean',  'lb',  'Luxembourgish',  'It',  'Lithuanian',  'lv',  'Latvian',  'mk', 
'Macedonian',  'ml',  'Malayalam',  'mn',  'Mongolian',  'my',  'Burmese',  'nb', 
'Norwegian  Bokmal',  'ne',  'Nepali',  'nl',  'Dutch',  'nn',  'Norwegian  Nynorsk',  'os', 
'Ossetic',  'pa',  'Punjabi',  'pi',  ’Polish',  'pt',  'Portuguese',  'pt-br',  'Brazilian 
Portuguese',  'ro',  'Romanian',  'ru',  'Russian',  'sk',  'Slovak',  ’sF,  'Slovenian',  'sq', 
'Albanian',  'sr',  'Serbian',  'sr-latn',  'Serbian  Latin',  'sv',  'Swedish',  'sw',  'Swahili',  'ta', 
'Tamil',  'te',  'Telugu',  'th',  'Thai',  'tr',  'Turkish',  '«',  'Tatar',  'udm',  'Udmurt',  'uk', 
'Ukrainian',  'ur',  'Urdu',  'vi',  'Vietnamese',  'zh-cn',  'Simplified  Chinese',  'zh-hans', 
'Simplified  Chinese',  'zh-hant',  'Traditional  Chinese',  'zh-tw',  'Traditional  Chinese' 


Solo  agrega  el  codigo  de  tu  lenguaje  asi: 


LANGUAGE  CODE  = 'es-mx' 
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Tambien  agrega  'django. middleware. locale.LocaleMiddleware'  a la  variable 
MIDDLEWARE_CLASSES  del  archivo  de  conflguraciones,  solo  asegurate  de  que 
aparezca  despues  de  'django. contrib.sessions.middleware.SessionMiddleware'. 

Una  vez  hecho  esto,  recarga  la  pagina  de  indice  de  la  interfaz  administrativa.  Si 
esta  disponible  alguna  traduction  para  tu  lenguaje,  entonces  varias  partes  de  la 
interfaz  -como  “cambiar  contrasena”,  “cerrar  sesion”,  enlaces  que  se  encuentran  en 
la  parte  superior  de  la  pagina,  apareceran  en  tu  idioma. 

Para  conocer  mas  caracteristicas  basadas  en  internationalization,  puedes 
consultar  el  capitulol9, 


Da  clic  en  el  link  “Usuarios”  en  la  fila  de  “Usuarios”  para  ingresar  a la  pagina  de 
lista  de  usuarios  registrados. 


4 & 127.0t)l:8000/admin/auth/usef/ C | /*  Sii  ft 


1 Administration  de  Django 

Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesion 

Inicio  > Authentication  and  Authorization  > Usuarios 

Seleccione  usuario  a modificar 

^ Buscar 

~ Por  es  staff 

Accidn:  | [7]  Jjawtarj  0 de  1 seleccionados/as  Todos/as 


□ Nombre  de  usuario  a Email  address 

0 saul  saul@gmail.com 

1 usuario 


Nombre  Apellido  Es  staff 

© 


Por  es  superusuario 

Todos/as 


Por  activo 

Todos/as 


Imagen  6-3.  La  lista  de  cambios  de  usuarios. 

Esta  pagina  muestra  todos  los  usuarios  de  la  base  de  datos,  puedes  pensar  en  ella 
como  en  una  version  estilizada  de  una  consulta  SQL:  SELECT  * FROM  auth_user;  Si 
estas  siguiendo  estos  ejemplos,  asumiremos  que  solo  haz  agregado  un  usuario,  sin 
embargo  una  vez  que  agregues  mas  usuarios,  es  probable  que  encuentres  utiles  las 
opciones  para  filtrar,  ordenar  o buscar.  Las  opciones  para  filtrar  estan  en  el  lado 
derecho,  las  opciones  para  ordenar  estan  disponibles  dando  clic  en  la  cabecera  de  la 
columna  y la  caja  de  busqueda  esta  situada  en  la  parte  superior  y te  permitiran 
buscar  usuarios  por  su  nombre. 

Da  clic  en  el  nombre  de  un  usuario  que  hayas  creado,  para  editarlo. 


4 & 127J.01:8000/admin/auth/user/l/ v g / » ^ @ ft 


Imagen  6-4.  Un  formulario  para  editar  usuarios. 
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Esta  pagina  te  permite  cambiar  los  atributos  de  un  usuario,  tal  como  el  nombre, 
los  apellidos  y los  distintos  permisos.  (Observa  que  para  cambiar  la  contrasena  de  un 
usuario,  es  necesario  dar  clic  en  el  formulario  “cambiar  contrasena”,  en  el  link  “este 
formulario”,  debajo  del  campo  contrasena,  para  cambiar  el  codigo  hash.)  Otra  cosa 
que  debes  notar  es  que  los  distintos  campos,  utilizan  diferentes  widgets  -Por  ejemplo 
el  campo  fecha/tiempo  tiene  controles  como  un  calendario  y un  reloj,  los  campos 
booleanos  tienen  checkboxes,  los  campos  de  caracteres  tienen  una  simple  caja  de 
entrada  de  texto. 

Puedes  eliminar  un  registro,  dando  clic  en  el  boton  borrar,  que  se  encuentra  en  el 
lado  izquierdo  del  formulario.  La  interfaz  de  administracion  solicita  una 
confirmacion  para  prevenir  errores.  La  eliminacion  de  un  objeto  se  desencadena  en 
cascada,  y la  pagina  de  confirmacion  de  eliminacion  del  objeto  muestra  todos  los 
objetos  relacionados  que  se  eliminaran  con  el.  (Por  ejemplo,  si  borras  un  Editor; 
cualquier  libro  que  pertenezca  a ese  editor  sera  borrado  tambien.) 


^ & 127t).0J.:8000/admin/auth/userA/password/  v <*  | nn  igf  ft 


Administracion  ds  DjanQO  Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesion 


Inicio  > Authentication  and  Authorization  > Usuarios  > saul  > Cambiar  contrasena 

Cambiar  contrasena:  saul 

Introduzca  una  nueva  contrasena  para  el  usuario  saul. 

Contrasena:  ••••• 

Contrasena  ••••• 

(de  nuevo): 

Para  verificar,  introduzca  la  misma  contrasena  que  introdujo  arriba. 

IIJ-JJ.ll.ll-l.lULiJ.U 


Imagen  6-5.  Un  formulario  para  cambiar  contrasena  de  usuario. 

Puedes  agregar  un  nuevo  usuario,  dando  clic  en  “Agregar”  en  la  columna 
correspondiente,  en  la  pagina  de  inicio  de  la  interfaz  administrativa.  Esto  te  llevara  a 
una  pagina  vacia,  lista  para  que  la  rellenes. 

t ; ft  lZ7.0n.l:8000l/admin/»uth/user/idd/ vcl  Z1  S Si  © ft  = 


Administracion  de  Django  Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesion 


Inicio  > Authentication  and  Authorization  > Usuarios  > Agregar  usuario 

Agregar  usuario 

Primero  introduzca  un  nombre  de  usuario  y una  contrasena.  Luego  podra  configurar  opciones  adicionales  acerca  del  usuario. 


Nombre  de  usuario: 

admin 

Obligatorio.  Longitud  maxima  30  caracteres  alf< 

!/./+/-/_)  solamente. 

Contrasena: 

Confirmacion  de 
contrasena: 

Para  verificar,  introduzca  la  misma  contrasena  . 

que  introdujo  arriba. 

Guardar  y agregar  otro  Guardar  y continuar  editando  j 

Imagen  6-6.  Un  formulario  de  edicion  para  agregar  un  usuario. 

Te  daras  cuenta  que  la  interfaz  de  administracion  tambien  controla  por  ti  la 
validez  de  los  datos  ingresados.  Intenta  dejar  un  campo  requerido  (los  cuales 
aparecen  con  letras  en  negritas)  en  bianco  o poner  una  fecha  invalida  en  un  campo 
tipo  fecha  y veras  los  avisos  resaltados  en  rojo,  cuando  intentes  guardar  el  objeto, 
como  se  muestra  en  la  Imagen  siguiente: 
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^ & 127.0.01'.8000/admin/auth/u5er'add/ 


r c /*  IS  # = 


Administracion  de  Django 


Inicio  > Authentication  and  Authorization  > Usuarios  > 


Bienvenido,  saul.  Cambiar  contrasena  / Cerrar 


Agregar  usuario 

Primero  introduzca  un  nombre  de  usuario  y una  contrasena.  Luego  podra  configurar  opciones  adidonales  acerca  del  usuario. 


O Please  correct  the  errors  below. 


Nombre  de  usuario:  [saul 


s y @ /./+/-/_)  sola 


Contrasena: 


Guardar  y agregar  otro  Guardar  y continuar  editando 


Imagen  6-7.  Un  formulario  de  edition  mostrando  errores  de  validation. 

Cuando  editas  un  objeto  existente,  veras  el  boton  “Historia”  en  la  esquina 
superior  derecha  de  la  ventana.  Cada  cambio  realizado  a traves  de  la  interfaz  de 
administracion  es  registrado,  y puedes  examinar  este  registro  haciendo  clic  en  este 
boton  (mira  la  Imagen  6-8). 


^ ® 127.0.0A:8000/admin/auth/u5er/l/history/ 


Administracion  de  Django 


Inicio  > Authentication  and  Authorization  > Usuarios  > saul  > Historia 

Historia  de  modificaciones:  saul 

Fecha/hora  Usuario 

11  de  Noviembre  de  2014  a saul 

las  20:20 

11  de  Noviembre  de  2014  a saul 
las  20:46 


Accion 
Modifica  email. 

Modifica  email. 


e /> 


& & ft  = 


Bienvenido,  saul.  Cambiar  contrasena  / Cerrar 


Imagen  6-8.  Pagina  de  historia  de  un  objeto  en  Django. 

Agrega  tus  modelos  al  sitio  administrative 

Hay  una  parte  crucial  que  no  hemos  hecho  todavia.  Y es  agregar  nuestros  modelos  a 
la  interfaz  administrativa,  para  poder  agregar,  cambiar  y borrar  objetos  en  las  tablas 
de  la  base  de  datos  usando  una  interfaz  agradable.  Continuando  con  el  ejemplo  del 
capitulo  5,  previamente  definimos  en  nuestra  aplicacion  biblioteca,  tres  modelos: 
Editor,  Libro  y Autor. 

Dentro  del  directorio  interno  biblioteca  (misitio /biblioteca),  existe  un  archivo 
vacio  llamado  admin.py,  creado  automaticamente  por  el  comando  startapp 
agreguemosle  las  siguientes  lineas  de  codigo,  para  registrar  nuestros  tres  modelos: 


biblioteca/admin .py 


from  django.contrib  import  admin 

from  biblioteca.models  import  Editor,  Autor,  Libro 

admin. site.  register(Editor) 
admin. site. register(Autor) 
admin. site. register(Libro) 

Este  codigo  registra,  cada  uno  de  los  modelos  en  la  interfaz  administrativa,  para 
que  Django  nos  ofrezca  una  interfaz  para  cada  uno  de  los  modelos  registrados,  bajo 
el  nombre  de  la  aplicacion  y podamos  introducir  datos  directamente  en  ellos. 

Una  vez  que  hemos  hecho  esto,  podemos  navegar  a la  pagina  de  inicio  usando  un 
navegador  Web  en:  http://127.0.0.1:8000/admin/,  y podremos  ver  una  section 
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llamada  “Biblioteca”  con  enlaces  para  Autor,  Libros  y Editores.  (Si  estabas  ejecutando 
el  servidor  de  desarrollo,  es  necesario  detenerlo  e iniciarlo  de  nuevo  para  que  los 
cambios  surtan  efecto.) 

Django  usa  el  nombre  de  cada  uno  de  los  modelos,  para  presentarlos  en  la  interfaz 
administrativa,  sin  embargo  agrega  la  letra  “s”  para  mostrar  el  nombre  en  plural,  lo 
cual  no  siempre  es  lo  mas  adecuado,  si  quieres  mostrar  el  nombre  en  plural  usa  la 
opcion  verbose_name_plural  en  cada  clase  Meta  interna,  a la  que  le  quieras  agregar 
un  nombre  en  plural.  Agregale  uno  a cada  modelo  asi: 


class  Autor(models. Model): 

nombre  = models. CharField(max_length=30) 
apellidos  = models.  CharField(max_length=40) 
email  = models. EmailField() 

class  Meta: 

ordering  = ['nombre"] 
verbose_name_plural  = "Autores" 

def str (self):  # Unicode en  Python  2 

return  '%s  %s'  % (self. nombre,  apellidos) 

Ahora  tienes  una  completa  interfaz  administrativa  funcional  para  cada  uno  de  tus 
tres  modelos.  jEso  es  genial  no  crees! 

f ® localhost:8000/ admin/  -C|&(§  ™n  fe?  ft  = 


Administracion  d©  D j a n Q 0 Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesic 


Administracion  del  sitio 


Grupos 

Usuarios 

♦ Agregar 

♦ Agregar 

✓ Modificar 
,/Modificar 

Mis  acciones 

./The  guia  defintive  to  Django 

Autores 

♦Agregar 

✓ Modificar 

Editores 

♦Agregar 

,/Modificar 

Libros 

♦ Agregar 

✓ Modificar 

Imagen  6-9.  Pagina  de  inicio  de  la  interfaz  administrativa. 

Tomate  un  momento  para  agregar,  cambiar  e insertar  algunos  registros  mas  en  tu 
base  de  datos.  Si  estas  siguiendo  los  ejemplos,  en  especial  los  del  capitulo5  cuando 
agregamos  objetos  mediante  la  terminal  al  modelo  Editor  (y  no  los  borraste),  puedes 
ver  esos  registros  en  la  pagina  de  listado  de  editores. 

Una  caracteristica  que  vale  la  pena  mencionar,  es  que  el  sitio  administrative 
maneja  las  relaciones  foraneas  y las  relaciones  muchos  a muchos,  las  cuales  aparecen 
en  el  modelo  Libro,  si  recuerdas  asi  es  como  definimos  el  modelo: 

class  Libro(models.  Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 
editores  = models.  ForeignKey(Editor) 
fecha_publicacion  = models. DateField() 

def str (self): 

return  self.titulo 

Observa  que  el  sitio  de  administracion,  contiene  una  pagina  “Agregar  libro” 
ubicada  en:  http://127.0.0.1:8000/admin/biblioteca/libro/add/,  donde  tenemos 
distintos  tipos  de  campos  como  el  de  los  editores  (una  “relation  foranea” 


no 
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ForeignKey),  la  cual  es  representada  por  una  caja  de  selection  y tenemos  el  campo 
autores  (Una  relation  “Muchos  a muchos”  ManyToManyField),  la  cual  es 
representada  por  una  caja  de  selection  multiples.  Ambos  campos  estan  situados  al 
lado  de  un  icono  verde  que  permite  agregar  registros  a las  relaciones.  Por  ejemplo  si 
das  clic  en  el  icono  verde  (un  signo  de  “mas”)  en  un  campo  de  “editores”  veras  una 
ventana  flotante  que  te  permitira  agregar  un  editor.  Despues  de  que  hayas  creado 
satisfactoriamente  un  editor  en  la  ventana  flotante,  el  formulario  “Agregar  libro” 
mostrara  una  actualization  con  el  nuevo  editor  creado. 

f $ 127t).01:8000/admin/biblioteca/libro/add/  ^ I ■ § A = 


AdminiStrSCiOn  dG  Djsngo  Bienvenido,  saul.  Cambiar  contrasefia  / Cerrar  sesion 


Inicio  > Biblioteca  > Libros  > Agregar  libro 


Agregar  libro 


Titulo: 

Autores: 

Adrian  Holovaty  * 

* 

a|jn  9f1a  „r  ( |(  ,r 

i • m-  A 

Editor: 

0* 

Fecha 

publicacion: 

Hoy  | f§ 

Note:  You  are  6 hours  behind  server  time. 

Portada: 

| Browse_  No  file  selected. 

Guardar  y agregar  otro  Guardar  y continuar  editando 

Imagen  6-10.  Formulario  para  agregar  libros,  en  la  interfaz  administrativa. 

Como  trabaja  la  interfaz  administrativa 

Detras  de  escena,  la  forma  en  que  trabaja  la  interfaz  administrativa,  es  bastante 
directa. 

Al  iniciar  el  servidor,  Django  carga  tus  URLconf  de  urls.py  y ejecuta  la  declaration 
admin.autodiscoverO  (que  es  habilitada  por  omision),  la  cual  se  encarga  de  activar  la 
interfaz  administrativa.  Esta  funcion  itera  sobre  cada  una  de  las  aplicaciones  listadas 
en  INSTALLED_APPS  y busca  un  archivo  11am ado  admin.py  en  cada  una  de  las 
aplicaciones  instaladas.  Si  existe  un  archivo  admin.py,  ejecuta  el  codigo  del  archivo. 
(Django  automaticamente  busca  un  modulo  admin  en  cada  una  de  las  aplicaciones  y 
lo  importa.) 

En  el  archivo  admin.py  de  nuestra  aplicacion  biblioteca,  cada  una  de  las  llamadas 
a admin.site.registerO  simplemente  registra  cada  uno  de  los  modelos  en  la  interfaz 
administrativa. 

De  esta  forma  el  sitio  administrative  mostrara  una  interfaz,  que  nos  permitira 
editar/cambiar  cada  uno  de  los  modelos  que  hayamos  explicitamente  registrado. 

La  aplicacion  django.contrib.auth  incluye  su  propio  archivo  admin.py,  por  lo  que 
tanto  Usuarios  y Grupos  aparecieron  automaticamente  en  la  interfaz  administrativa. 
Otras  aplicaciones  de  django.contrib,  tal  como  django.contrib.redirects  tambien 
pueden  agregarse,  asi  como  muchas  de  las  aplicaciones  de  terceros  que 
descarguemos  de  la  Web. 

Mas  alia  de  esto,  la  interfaz  administrativa  es  solo  una  aplicacion  Django,  la  cual 
incluye  sus  propios  modelos,  plantillas,  vistas  y patrones  URL.  Puedes  agregarla  a tus 
aplicaciones  simplemente  anclandola  a tus  URLconfs,  tal  como  lo  harfas  con  una 
vista.  Puedes  inspeccionar  sus  plantillas,  vistas  y patrones  URL,  las  cuales  se 
encuentran  en  django/contrib/ admin,  en  la  copia  de  tu  codigo  base  - Pero  no 
intentes  cambiar  nada  directamente,  ya  que  existen  otras  formas  para  cambiar  y 
personalizar  la  manera  en  que  trabaja  el  sitio  administrative.  (Si  decides  hurgar  en  la 
interfaz  administrativa  ten  en  cuenta  que  esta  realiza,  una  gran  cantidad  de  cosas 
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bastante  complicadas  leyendo  los  metadatas  de  los  modelos,  asi  que  probablemente 
te  tomara  un  buen  tiempo  leer  y comprender  el  codigo.) 

Como  crear  campos  opcionales 

Despues  de  jugar  un  rato  con  el  sitio  de  administration,  probablemente  encuentres 
algunas  limitaciones  - las  formas  para  editar  requieren  que  todos  los  campos  sean 
completados,  sin  embargo  en  algunos  casos  es  necesario  que  algunos  campos  sean 
opcionales.  Digamos  por  ejemplo,  que  queremos  que  un  modelo  Autor  contenga  un 
campo  email  que  sea  opcional  - es  decir  que  permita  cadena  en  bianco.  En  el  mundo 
real,  un  autor  puede  no  tener  una  direccion  de  correo  electronico  o email . 

Para  especificar  que  un  campo  email  sea  opcional,  edita  el  modelo  Autor  (el  cual 
creamos  en  el  capitulo5,  y que  se  encuentra  en  misitio/biblioteca/models.py). 
Simplemente  agrega  blank=True  al  campo  email  asi: 

class  Autoi  (models. Model): 

nombre  = models.  CharField(max_length=30) 
apellidos  = models.  CharField(max_length=40) 
email  = models. EmailField(blank=True) 

Esto  le  dice  a Django  que  los  valores  en  bianco  estan  permitidos  en  el  campo  email 
de  la  tabla  Autor.  Por  omision,  todos  los  campos  se  asignan  con  blank=False,  lo  cual 
no  permite  valores  en  bianco. 

Veamos  algunas  cosas  interesantes  que  pasan  aqui:  hasta  ahora  con  la  exception 

del  metodo str (),  nuestros  modelos  ha  servido  como  definiciones  para  las  tablas 

de  la  base  de  datos  -Esencialmente  expresiones  Pythonicas  de  la  sentencia  CREATE 
TABLE  de  SQL.  Agregando  blank=True,  hemos  comenzado  a desplegar  nuestro 
modelo  mas  alia  de  una  simple  definition  de  tablas  de  nuestra  base  de  datos.  Ahora 
nuestro  modelo  de  clases  empieza  a ser  una  rica  coleccion  de  definiciones  acerca  del 
objeto  Autor  y lo  que  puede  hacer.  No  unicamente  es  el  campo  email  que  representa 
una  columna  VARCITAR  en  la  base  de  datos,  es  tambien  un  campo  opcional  dentro 
del  contexto  de  la  interfaz  administrativa. 

Una  vez  que  hemos  agregado  blank=True,  recarga  el  formulario  “Agregar  autor” 
en:  http://127.0.0.1:8000/admin/biblioteca/autor/add/  y podras  darte  cuenta  que  la 
etiqueta  -’’Email”-  ya  no  esta  en  negritas.  Esto  significa  que  el  campo  ya  no  es 
requerido.  Podemos  agregar  ahora  autores  sin  necesidad  de  proveer  una  direccion  de 
email;  por  lo  que  ya  no  veremos  el  campo  marcado  de  rojo  que  nos  dice  el  mensaje 
“Este  campo  es  requerido”,  ya  que  ahora  podemos  dejar  el  campo  vacio. 

Como  crear  campos  numericos  y de  fechas  opcionales 

Un  problema  comun  relacionado  con  campos  en  blancos  o "blank=True"  tiene  que 
ver  con  los  campos  numericos  y de  fechas,  este  tema  requiere  un  poco  de  explication 
afondo. 

SQL  tiene  sus  propias  maneras  de  especificar  los  valores  en  bianco  - un  valor 
especial  llamado  NULL.  NULL  significa  “desconocido”  o “no  valido”  u algun  otro 
significado  especifico. 

En  SQL  un  valor  NULL  es  diferente  que  una  cadena  vacia,  tal  como  el  objeto 
especial  Python  None,  que  es  diferente  a una  cadena  vacia  en  Python  ("").  Esto 
significa  que  es  posible  que  un  campo  de  caracteres  particular  (por  ejemplo  una 
columna  VARCHAR ) contenga  ambos  valores:  NULL  y una  cadena  vacia. 

Esto  puede  causar  cierta  ambigiiedad  y confusion,  ^’’Porque  este  registro  tiene  un 
valor  NULL  y este  otro  una  cadena  vacia”?  ^Existe  una  diferencia  o fueron  los  datos 
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registrados  inconsistentemente?  y como  obtengo  todos  los  registros  que  tienen  un 
valor  en  bianco  - busco  ambos  registros  o unicamente  selecciono  las  cadenas  vacia. 

Para  ayudar  a evitar  estas  ambigiiedades,  Django  automaticamente  genera  un 
declaracion  CREATE  TABLE  (Que  cubrimos  en  el  capitulo  5)  y agrega  explicitamente 
en  cada  columna  una  definition  NOT  NULL.  Por  ejemplo  esta  es  la  declaracion 
generada  por  el  modelo  Autor  del  capitulo  5: 

CREATE  TABLE  "biblioteca_autor"  ( 

"id"  serial  NOT  NULL  PRIMARY  KEY, 

"nombre"  varchar(30)  NOT  NULL, 

"apellidos"  varchar(40)  NOT  NULL, 

"email"  varchar(75)  NOT  NULL 

); 


En  la  mayoria  de  los  casos,  este  comportamiento  por  omision  es  optimo  para 
usarlo  en  nuestras  aplicaciones  y nos  ayudara  a guardar  nuestros  datos  y evitar 
inconsistencias  y dolores  de  cabeza,  tal  como  el  sitio  de  administration  que  inserta 
cadenas  vacias  (no  valores  NULL  ) cuando  dejamos  un  campo  de  caracteres  en 
bianco. 

Pero  existe  una  exception  con  algunas  columnas  de  la  base  de  datos  que  no 
aceptan  cadenas  vacias  - por  ejemplo  los  de  tipo  fechas,  y los  numericos.  Si  intentas 
insertar  una  cadena  vacia  en  una  columna  de  tipo  fecha  o numero  entero,  solo 
conseguiras  un  error  de  la  base  de  datos,  dependiendo  de  la  base  de  datos  que  estes 
utilizando  (PostgreSQL  es  estricta  y lanzara  una  exception;  MySQL  puede  aceptar  o 
no  dependiendo  de  la  version  que  estes  usando,  el  tiempo,  el  dia  y la  fase  de  la  luna) 
En  este  caso  NULL  es  unicamente  una  forma  de  especificar  que  el  valor  esta  vacio.  En 
los  modelos  de  Django,  puedes  especificar  NULL  agregando  null=True  a los  campos, 
donde  sea  necesario. 

De  modo  que  existe  una  manera  mas  larga  de  decir  esto:  si  quieres  permitir 
valores  en  bianco  en  un  campo  (por  ejemplo:  DateLield,  TimeLield,  DateTimeLield)  o 
numerico  (por  ejemplo:  IntegerLield,  DecimalLield,  LloatLield),  necesitas  agregar 
ambos  tipos:  null=True  y blank=True. 

Para  ejemplificar  mejor  lo  anterior,  cambiemos  el  modelo  Libro  para  que  el  campo 
fecha_publicacion  permita  espacios  en  bianco  y valores  nulos.  Este  es  el  codigo 
revisado: 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 
editores  = models. ForeignKey(Editor) 

fecha_publicacion  = models. DateField(blank=True,  null=True) 
portada  = models. lmageField(upload_to='portadas') 

Agregar  null=True  es  mas  complicado  que  agregar  blank=True,  porque  null=True 
cambia  la  semantica  de  la  base  de  datos  - esto  es,  cambia  la  declaracion  CREATE 
TABLE  para  que  remueva  del  campo  fecha_publicacion,  la  declaracion  NOT  NULL  de 
la  base  de  datos  -.  Para  completar  este  cambio  necesitamos  actualizar  el  esquema  de 
la  base  de  datos. 

En  versiones  anteriores  de  Django  para  actualizar  la  base  de  datos,  necesitabamos 
manualmente  usar  el  interprete  de  comandos  (especifico  de  cada  base  de  datos)  y 
utilizar  SQL  para  alterar  el  esquema  de  la  base  de  datos,  una  vez  que  habiamos 
sincronizado  nuestros  modelos.  Sin  embargo  esto  ya  no  es  necesario  (aunque  hay  sus 
excepciones),  ya  que  podemos  usar  las  migraciones  para  realizar  estas  tareas, 
recuerdas  los  tres  pasos  que  seguimos  para  instalar  los  modelos: 
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■ Cambia  tu  modelo  (en  models. py). 

■ Ejecuta  manage.py  makemigrations  para  crear  las  migraciones  para  esos 
cambios. 

■ Ejecuta  manage.py  migrate  para  aplicar  esos  cambios  a la  base  de  datos. 

Cada  vez  que  cambiemos  nuestros  modelos,  es  necesario  ejecutar  estos  dos 
comandos  para  sincronizar  los  cambios  en  el  esquema  de  la  base  de  datos 
automaticamente. 

Una  vez  que  hayamos  creado  las  migraciones,  sincronizando  los  modelos  (para 
agregar  valores  nulos  y campos  en  bianco),  traemos  de  vuelta  la  interfaz 
administrativa,  ahora  el  formulario  “Agregar  libro”  permite  publicar  valores  vacios  en 
el  campo  fecha_publicacion  y lo  mejor  de  todo  es  que  no  tenemos  que  ejecutar  SQL 
directamente. 

Personalizar  las  etiquetas  de  los  campos 

En  los  formularios  del  sitio  de  administration,  cada  etiqueta  de  texto  es  generada,  de 
cada  uno  de  los  nombres  de  cada  campo.  El  algoritmo  es  simple:  Django  reemplaza 
los  guiones  bajos  con  espacios  y pone  en  mayuscula  la  primera  letra  de  la  palabra.  Asi 
que  por  ejemplo,  en  el  modelo  libro,  el  campo  fecha_publicacion  tiene  la  etiqueta 
“Fecha  publication” 

De  cualquier  manera,  el  nombre  de  los  campos  no  siempre  se  presenta  de  una 
forma  agradable  en  las  etiquetas  de  texto,  en  algunos  casos  lo  mas  recomendable  es 
personalizar  la  etiqueta.  Para  hacerlo  es  necesario  especificarlo  con  la  etiqueta 
verbose_name  en  el  campo  del  modelo. 

Por  ejemplo,  asi  es  como  podemos  cambiar  la  etiqueta  del  campo  Autor  email  a 
“e-mail”  con  un  guion  en  medio: 

class  Autor(models. Model): 

nombre  = models.  CharField(max_length=30) 

apellidos  = models.  CharField(max_length=40) 

email  = models. EmailField(blank=True,  verbose_name- e-mail') 

Para  que  los  cambios  surtan  efecto,  recarga  el  servidor  y podras  ver  la  nueva  etiqueta 
de  texto  e-mail,  en  el  formulario  para  editar  autores. 

Observa  que  no  necesitas  poner  en  mayuscula  la  primera  letra  de  la  palabra 
cuando  utilizas  verbose_name  ya  que  esta  siempre  sera  mostrada  con  la  primera 
palabra  en  mayusculas,  a menos  de  que  ha  si  lo  requieras  (por  ejemplo:  "USA 
estate").  Django  automaticamente  usara  la  mayuscula  cuando  lo  necesite  y mostrara 
la  salida  exacta  del  valor  verbose_name  en  otros  lugares  que  no  requieran 
mayusculas. 

Finalmente,  nota  que  puedes  pasar  argumentos  posicionales  a verbose_name, 
para  lograr  una  sintaxis  ligeramente  mas  compacta.  Este  ejemplo  es  equivalente  al 
anterior: 

class  Autor(models. Model): 

nombre  = models.  CharField(max_length=30) 
apellidos  = models.  CharField(max_length=40) 
email  = models. EmailField('e-mair,  blank=True) 

Aunque  ten  en  cuenta,  que  esto  no  trabaja  con  campos  ManyToManyField  o 
ForeignKey,  porque  estas  relaciones  requieren  como  primer  argumento  un  modelo 
de  clase.  En  estos  casos,  es  necesario  especificar  explicitamente  verbose_name  de  la 
forma  habitual. 


114 


CAPITULO  6 LA  INTERFAZ  ADMINISTRATIVA 


Clases  personalizadas  de  la  interfaz  administrativa 

Los  cambios  que  hemos  realizado  hasta  ahora  blank=True,  null=True  y 
verbose_name  son  realmente  a nivel  de  modelos,  no  a nivel  administrativo.  Es  decir 
estos  cambios  son  fundamentalmente  una  parte  del  modelo  y solo  ocurren  cuando 
usamos  el  sitio  administrativo,  por  lo  que  no  hay  nada  especifico  acerca  de  ellos. 

Mas  alia  de  esto,  el  sitio  administrativo  ofrece  abundantes  opciones  que  te 
permiten  modilicar  la  forma  en  que  el  sitio  administrativo  trabaja  para  determinados 
modelos.  Estas  opciones  se  encuentran  en  las  clases  ModelAdmin,  que  son  las  clases 
que  contienen  la  configuration  especifica  para  un  modelo,  de  una  instancia  del  sitio 
administrativo. 

Personalizar  la  lista  de  cambios 

Vamos  a sumergirnos  en  la  personalization  de  la  interfaz  administrativa, 
especificando  que  campos  seran  mostrados  en  la  lista  de  cambios  del  modelo  Autor. 
Por  omision,  la  lista  de  cambios  solo  muestra  la  cadena  de  representation  del 

modelo  que  agregamos  con  el  metodo str , en  el  capitulo5,  definimos  un  metodo 

str para  el  objeto  Autor  que  muestra  el  primer  nombre  y los  apellidos  juntos  asi: 

class  Autor(models. Model): 

nombre  = models.  CharField(max_length=30) 

apellidos  = models.  CharField(max_length=40) 

email  = models. EmailField(blank=True,  verbose_name- e-mail') 

def str (self): 

return  '%s  %s'  % (self.nombre,  self.apellidos) 


Como  consecuencia  de  estos  cambios,  la  lista  de  cambios  para  el  objeto  Autor 
muestra  juntos  el  nombre  y los  apellidos,  como  puedes  ver  en  la  Imagen  6-11. 


^ 127.0.0.1:8000/admin/biblioteca/autor/  • C I & §=3  nn  ?\\  "ft 


1 Administration  de  Django 

Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesion  1 

Inicio  > Biblioteca  > Autores 

Seleccione  autor  a modificar 

Accion:  | |t|  Ejecutar 

1 de  1 selecc 

ionados/as 

Irl  Autor 

0 Adrian  Holovaty 

1 autor 

Imagen  6-11.  Pagina  de  lista  de  cambios  del  modelo  Autor. 

Podemos  pulir  este  comportamiento  predeterminado  agregando  algunos  campos 
mas  a la  lista  de  cambios.  Seria  conveniente,  por  ejemplo  ver  el  correo  electronico  de 
cada  autor  y seria  agradable  poder  ordenarlos  por  nombres  y apellidos. 

Para  hacer  que  esto  suceda,  necesitamos  definir  una  clase  ModelAdmin  para  el 
modelo  Autor.  Esta  clase  es  la  clave  para  personalizar  la  interfaz  administrativa  y una 
de  las  cosas  basicas  que  nos  permite  hacer,  es  especilicar  la  lista  de  campos  que 
queremos  visualizar  en  la  lista  de  cambios. 

Edita  el  archivo  admin. py  para  realizar  estos  cambios. 

from  django.contrib  import  admin 

from  biblioteca.models  import  Editor,  Autor,  Libro 
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class  AutorAdmin(admin.ModelAdmin): 

list_display  = ('nombre',  'apellidos',  'email') 

admin. site.  register(Editor) 

admin. site. register(Autor,  AutorAdmin) 

admin. site.  register(Libro) 

Esto  es  lo  que  hicimos: 

■ Creamos  la  clase  AutorAdmin.  Esta  clase,  la  cual  es  una  subclase  de 
django.contrib.admin.ModelAdmin,  se  encarga  de  llevar  a cabo  la 
configuration  para  un  modelo  especifico  de  la  interfaz  administrativa. 
Unicamente  especificamos  una  personalization  -list_display,  la  cual  es  una 
tupla  de  nombres  de  campos,  que  controla  que  columnas  aparecen  en  la  lista 
de  cambios.  Siempre  y cuando  estos  nombres  de  campos,  existan  en  el 
modelo. 

■ Alteramos  la  llamada  a admin. site. registerO,  para  agregar  AuthorAdmin 
despues  de  Autor. 

Puedes  leer  esto  como:  “Registra  el  modelo  Autor  con  las  opciones  de 
AuthorAdmin.” 

La  funcion  admin.site. registerO  toma  un  subclase  ModelAdmin  como  un 
segundo  argumento  opcional.  Si  no  necesitas  especificar  un  segundo 
argumento  (como  en  el  caso  de  Editor  y de  Libro)  Django  usara  por  omision 
las  opciones  administrativas  para  el  modelo. 

Con  estos  cambios  realizados,  recarga  la  lista  de  cambios  de  autor  y ahora  podras 
ver  tres  columnas  -Nombre,  Apellidos  y E-mail.  En  suma,  cada  uno  de  estas 
columnas  se  puede  ordenar  dando  clic  en  la  cabecera  de  la  columna.  (Ve  la  Imagen  6- 
12) 


el  ☆ 6 !!!  Si  £>  * = 


Administration  de  Django  Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesion 


Inicio  > Biblioteca  > Autores 


^ tji  127.0.0.1 :8000  ■ a cl  m in  ■'  b i b 1 1 ctec  a a jt  c r 


Seleccione  autor  a modificar 


Agregar  autor  + 


2 Ejecutar 


0 de  1 seleccionados/as 


0 Nombre  * Apellidos 

0 Adrian  Holovaty 


1 autor 


E-mail 

adrian@example.com 


Imagen  6-12.  La  pagina  de  lista  de  cambios  de  autor,  despues  de  usar  “list_display” 

Ahora,  agreguemosle  una  barra  de  busqueda.  Agrega  search_flelds  a la  clase 
AutorAdmin,  asi: 

class  AutorAdmin(admin. ModelAdmin): 
list_display  = ('nombre',  'apellidos'  'email') 

search_fields  = ('nombre',  'apellidos') 

Recarga  la  pagina  en  tu  navegador  y podras  observar  una  barra  de  busqueda  en  la 
parte  superior  (Observa  la  Imagen  6-9.).  Acabamos  de  informarle  a la  lista  de  cambios 
que  incluya  una  barra  de  busqueda,  que  se  encargue  de  buscar  en  los  campos 
nombre  y apellidos  de  la  base  de  datos.  Como  cualquier  usuario  pudiera  esperar,  no 
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distingue  entre  mayusculas  y minusculas  y busca  en  ambos  campos,  asi  que  si 
buscamos  la  palabra  "bar"  podriamos  encontrar  un  autor  llamado  “Barney”  y 
tambien  otro  autor  cuyo  apellido  sea  “Hobarson”. 


Imagen  6-13.  Lista  de  cambios,  despues  de  agregar  “ search  Jields”. 

Despues,  podemos  agregar  algunos  filtros  al  modelo  Libro  para  mostrar  la  lista  de 
cambios,  por  fechas  de  publicaciones: 

from  django.contrib  import  admin 

from  biblioteca.models  import  Editor,  Autor,  Libro 

class  AutorAdmin(admin.ModelAdmin): 
list_display  = ('nombre',  apellidos',  'email') 
search_fields  = ('nombre',  'apellidos') 

class  LibroAdmin(admin.ModelAdmin): 

list_display  = ('titulo',  'editor',  'fecha_publicacion') 

list_filter  = ('fecha^publicacion',) 

admin. site.  register(Editor) 

admin. site. register(Autor,  AutorAdmin) 

admin. site. register(Libro,  LibroAdmin) 


Ahora  visita  la  pagina  de  lista  de  cambios  de  libros: 

^ localhost:8000/admin/biblioteca/libro/?o=4.-l  C ^ S!i  Ifiji  "ft 


AdminiStraCiOn  d©  Django  Bienvenido,  saul.  Cambiarcontrasefia/Cerrarsesion 


Inicio  > Biblioteca  > Libros 


Seleccione  libro  a modificar 

Action:  <r|  Secular  | : de  1 seleccionados/as 

Filtrar  j* 

0 Titulo 

▼ Editor 

Fecha  publicacion 

eor lecna 
publicacion 

0 The  guia  defintive  to  Django 

Apress 

10  de  Noviembre  de  2014 

] Cualquier  fecha 

Hoy 

1 libro 

Ultimos  7 dfas 

Este  mes 

Este  ano 

Imagen  6-14.  Lista  de  cambios,  despues  de  aplicar  algunos  filtros. 


Aqui  vemos  porque  usamos  diferentes  tipos  de  opciones,  primero  hemos  creado 
una  nueva  a clase  separada  de  ModelAdmin  llamada  LibroAdmin.  Primero  definimos 
list_display  solo  para  mostrar  la  lista  de  cambios  de  forma  mas  agradable.  Luego 
usamos  list_filter,  la  cual  es  una  tupla  de  campos  que  se  usa  para  crear  filtros  a lo 
largo  de  la  barra  lateral,  del  lado  derecho  de  la  lista  de  cambios.  Para  los  campos  de 
fechas  Django  provee  algunos  atajos  para  filtrar  las  listas,  tal  como  “Hoy”,  “Ultimos  7 
dias”,  “Este  mes”  y “Este  ano”  -atajos  que  los  desarrolladores  de  Django  han 
encontrado  muy  utiles  para  casos  en  lo  que  se  necesite  filtrar  por  fechas.  La  Imagen 
6-14  muestra  la  forma  en  que  lucen. 
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Otra  forma  de  ofrecer  los  filtros  basados  en  fechas  es  usando  la  option 
date_hierarchy  asi: 

class  LibroAdmin(admin.ModelAdmin): 

list_display  = ('titulo',  'editor',  'fecha_publicacion') 
list_filter  = ('fecha_publicacion',) 

date_hierarchy  = 'fecha^publicacion' 

Con  esto  en  su  lugar,  la  lista  de  cambios  obtiene  una  barra  de  navegacion 
desplegable  en  la  parte  superior  de  la  lista,  como  se  muestra  en  la  Imagen  6-11.  Esta 
comienza  con  una  lista  desplegable  de  anos,  de  meses  y termina  con  los  dias  de 
forma  individual. 

localho$t:8000/admin/biblioteca/libro/?o=4,-l 


Administration  de  Django 


Inicio  > Biblioteca  • Libros 

Seleccione  libro  a modificar 

| < 2014  10  de  Noviembre 

Accion:  | Qecutar  | 0 de  1 seleccionados/as 

H Titulo  v Editor  Fecha  publicacion 

□ The  guia  defintive  to  Django  Apress  10  de  Noviembre  de  2014 

1 libro 


c|  "Cr  £ S & # = 


Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesic 


gEBBP 


Por  fecha 
publicacion 

j|  Cualquier  fecha 


Imagen  6-15.  Lista  de  cambios,  despues  de  agregar  “datejiierarchy”. 

Observa  que  la  opcion  datejiierarchy  toma  una  cadena,  no  una  tupla  porque 
unicamente  toma  un  campo  de  tipo  fecha,  el  cual  ha  sido  usado  para  crear  la 
jerarquia. 

Finalmente,  tambien  podemos  cambiar  el  ordenamiento  por  omision  de  la  pagina 
de  inicio  de  la  lista  de  cambios,  para  que  siempre  sean  ordenados  en  orden 
descendiente  de  acuerdo  a la  fecha  de  publicacion.  Por  omision  el  orden  de  los 
objetos  en  la  lista  de  cambios  se  da  de  acuerdo  al  orden  especificado  en  el  modelo 
con  ordering  en  la  class  Meta  (La  cual  cubrimos  en  el  capitulo  5)  -pero  como  aun  no 
hemos  especificado  este  valor  ordering,  el  ordenamiento  es  aun  indefinido. 

class  UbroAdmin(admin.ModelAdmin): 

list  display  = ('titulo',  'editor',  'fecha_publicacion') 
list_filter  = ('fecha_publicacion',) 
datejiierarchy  = 'fecha_publicacion' 

ordering  = (,-fecha_publicacion',) 

La  opcion  ordering  trabaja  exactamente  como  lo  hace  en  los  modelos  dentro  de  la 
clase  interna  class  Meta,  excepto  que  unicamente  usa  el  primer  nombre  de  un  campo 
en  la  lista.  Solo  pasa  una  tupla  a la  lista  de  nombres  de  campos,  y agrega  un  signo  (-) 
al  campo  para  usarlo  en  orden  descendente. 

Hasta  aqui,  hemos  cubierto  las  principales  opciones  de  la  lista  de  cambios. 
Usando  estas  opciones,  puedes  crear  interfaces  muy  poderosas  y listas  para  producir 
y editar  datos,  agregando  solo  algunas  pocas  lineas  de  codigo 

Personalizar  formularios  de  edicion 

Al  igual  que  las  listas  de  cambios  que  pueden  ser  hechas  a la  medida,  los  formularios 
para  edicion  pueden  personalizarse  de  muchas  maneras. 

Primero,  personalicemos  los  campos  y la  forma  en  que  son  ordenados.  Por 
omision  el  orden  de  un  campo  en  una  forma  o formulario  de  edicion,  corresponde  al 
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orden  en  el  que  se  haya  definido  en  el  modelo.  Sin  embargo  podemos  cambiar  el 
ordenamiento,  usando  la  opcion:  fields  en  una  subclase  de  ModelAdmin. 


class  LibroAdmin(admin. ModelAdmin): 

list_display  = ('titulo',  'editor',  'fecha_publicacion') 
list_filter  = ('fecha_publicacion',) 
date_hierarchy  = 'fecha_publicacion' 
ordering  = ('-fecha_publicacion',) 

fields  = ('titulo',  'autores',  'editor',  'fecha_publicacion') 

Despues  de  realizar  estos  cambios,  la  forma  para  editar  libros,  utilizara  el  orden 
definido  con  fields  . Es  mas  natural  tener  autores  despues  del  titulo  del  libro.  Aunque 
el  orden  de  los  campos  dependent  de  tu  flujo  de  trabajo  y de  la  entrada  de  los  datos 
que  manejes.  Cada  forma  de  trabajo  es  diferente. 

Otra  cosa  util,  la  opcion  fields  permite  que  excluyas  ciertos  campos  de  un 
formulario.  Solo  deja  fuera  el  campo  que  quieres  excluir.  Esto  puede  ser  util  si  los 
usuarios  administradores  en  quienes  confias  unicamente  quieren  editar  una  parte  de 
los  datos,  o si  una  parte  de  los  campos  son  cambiados  desde  fuera  digamos,  mediante 
un  proceso  automatico.  Por  ejemplo  en  la  base  de  datos  biblioteca,  podemos  ocultar 
el  campo  fecha_publicacion  para  que  no  sea  editable  por  los  usuarios. 

class  LibroAdmin(admin. ModelAdmin): 

list_display  = ('titulo',  'editor',  'fecha_publicacion') 
list_filter  = ('fecha_publicacion',) 
date_hierarchy  = 'fecha_publicacion' 
ordering  = ('-fecha_publicacion',) 
fields  = ('titulo',  'autores',  'editor',  'portada') 

Como  resultado,  la  forma  para  editar  biblioteca,  no  ofrece  una  forma  para 
especificar  la  fecha  de  publicacion.  Esto  puede  ser  util  en  algunos  casos,  digamos  por 
ejemplo  que  eres  un  editor  que  prefiere  que  sus  autores  no  especifiquen  la  fecha  de 
publicacion  (Claro  que  esto,  es  solo  un  ejemplo  hipotetico.) 


^ j ® Iocalhost8000/admin/biblioteca/libro/add/  C J"  nn  r\\  ft 


Administracion  ds  Django  Bienvenido,  saul.  Cambiar  contrasena  / Cerrar  sesic 


Inicio  > Biblioteca  > Libros  > Agregar  libro 


Agregar  libro 


Titulo: 

Autores: 

Adrian  Holovaty  ♦ 

* 

Editor: 

0* 

Portada: 

[ Browse-  No  file  selected. 

Guardar  y agregar  otro  Guardar  y continuar  editando  | 

Imagen  6-16.  Uso  de  “field”  para  mostrar  campos 

De  esta  forma  cuando  un  usuario  sube  el  formulario  sin  el  campo 
fecha_publicacion,  para  agregar  un  libro,  Django  simplemente  trata  el  campo  como 
None  - ya  que  el  campo  acepta  valores  nulos,  que  definimos  con  la  opcion: 
null=True,  por  lo  que  puede  quedar  en  bianco. 

Otro  uso  muy  comun  para  usar  formularios  personalizados,  se  da  al  usar  campos 
muchos  a muchos.  Tal  como  vimos  en  el  formulario  para  editar  libros,  en  la  interfaz 
administrativa  esta  cuenta  con  una  caja  de  selection  multiple,  que  representa  un 
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campo  ManyToManyField,  el  cual  logicamente  usa  un  widget  HTML  para  la  entrada 
de  datos  -sin  embargo  las  caja  de  seleccion  multiple  puede  dificultar  su  uso.  Si 
quieres  seleccionar  multiples  objetos,  tienes  que  mantener  presionada  la  tecla 
“control”  o “comando”  en  Mac  (el  sitio  de  administration  inserta  algunos  fragmentos 
de  texto  en  forma  de  ayuda  que  explican  esto),  sin  embargo  esto  se  vuelve 
inmanejable  cuando  el  campo  contiene  centenares  de  opciones. 

La  solution  es  cambiar  la  disposition  de  la  interfaz  administrativa  usando 
filter_horizontal. 

Agreguemos  esto  a LibroAdmin  y veamos  lo  que  ocurre. 

class  LibroAdmin(admin.ModelAdmin): 

list  display  = ('titulo',  'editor',  'fecha_publicacion') 
list_filter  = ('fecha_publicacion',) 
date_hierarchy  = 'fecha_publicacion' 
ordering  = ('-fecha_publicacion',) 
filter_horizontal  = ('autores',) 

(Si  estas  siguiendo  esto  interactivamente,  nota  que  removimos  la  option  fields 
para  restaurar  todos  los  campos  del  formulario.) 

Recarga  el  formulario  para  editar  libros  y podras  ver  que  ahora  la  section  de 
“Autores”  usa  una  interfaz  elegante  y un  filtro  en  Java  Script  que  permite  explorar  a 
traves  de  las  opciones  de  forma  dinamica,  lo  que  permite  encontrar  autores 
especificos  y permite  mover  de  “Autores  disponibles”  a la  caja  “Autores  elegidos”  y 
viceversa. 


t localhost  8000  admin/biblioteca/libro/add 


Administration  de  Django 


Inicio  > Biblioteca  > Libros  > Agregar  libro 


e 


» ft  = 


>aul.  Cambiar  contrasefia  / Cerrar  sesion 


Agregar  libro 


Titulo: 


Autores: 


Disponible  autores  © 

@ 

^ | Filtro 

Adrian  Holovaty 

Seleccionar  todos  O 0 E|imjnar  todos 


Editor:  t ^ 

Fecha  Hoy  | g) 

publics  cion:  Note;  You  are  6 houre  behjnd  server  time 

Portada:  | Browse,  [ No  file  selected. 


Guardar  y agregar  otro 


Guardar  y continuar  editando 


Imagen  6-17.  Formulario  para  editar  libros,  despues  de  agregar  “filter  horizontal”. 

Recomendamos  usar  el  filtro  horizontal,  filterjiorizontal  para  cualquier  campo 
ManyToManyField  que  contenga  mas  de  10  objetos.  Es  mas  sencillo  de  usar  que  el 
widget  de  seleccion  multiple.  Tambien  puedes  usar  filterjiorizontal  en  campos 
multiples  -solo  especifica  cada  nombre  en  una  tupla. 

La  clase  ModelAdmin  tambien  soporta  la  option  filtro  vertical,  filter_vertical.  La 
cual  trabaja  exactamente  como  filterjiorizontal,  pero  la  interfaz  Java  Script 
resultante,  es  una  pila  que  contiene  dos  cajas  verticales  en  lugar  de  una.  Todo  es 
cuestion  de  gustos  y necesidades. 
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*5-  localhost 


c[  / S (a>  = 


listracion  de  Django 


libro 


Titulo: 


Bienvenido,  saul.  Cambiar  contra sena  / Cerrar  sesion 


Editor:  [»  t 

Fecha  Hoy  | Q 

publicacion:  Note;  You  are  6 hours  server  time. 


| Browse  | No  file  selected. 


Imagen  6-18.  Formulario  para  editar  libros,  despues  de  agregar  "filter  vertical". 

Los  filtros  filterjiorizontal  y filter_vertical  unicamente  trabajan  con  campos 
ManyToManyField  no  asi  con  campos  ForeignKey.  Por  omision  la  interfaz 
administrativa  usa  simples  cajas  select,  para  mostrar  los  campos  ForeignKey,  pero  al 
igual  que  con  los  campos  ManyToManyField,  algunas  veces  sera  necesario  buscar  la 
forma  de  no  tener  que  seleccionar  todos  los  objetos  relacionados,  ya  que  si  nuestra 
base  de  datos  incluye  a millares  de  editores,  la  forma  para  “Agregar  libros”  puede 
tardar  un  buen  rato  en  cargarlos  a todos  (lo  que  genera  sobrecarga  en  la  base  de 
datos),  ya  que  tendria  que  cargar  a cada  editor  para  mostrar  la  caja  <select>. 

La  forma  de  corregir  esto  es  usar  una  option  llamada  raw_id_fields.  Colocando  en 
una  tupla  los  nombres  de  los  campos  de  el  ForeignKey,  para  mostrarlos  en  la  interfaz 
administrativa,  dentro  de  una  simple  caja  de  texto  (<input  type="text">)  en  lugar  de 
<select>. 

class  LibroAdmin(admin.ModelAdmin): 

list_display  = ('titulo',  'editor',  'fecha_publicacion') 
list_filter  = ('fecha_publicacion',) 
date_hierarchy  = 'fecha_publicacion' 
ordering  = ('-fecha_publicacion',) 
filterjiorizontal  = ('autores',) 
rawjd_fields  = ('editor',) 


♦>  localhost:8000/admin/biblioteca/l 


inistracion  de  Django 


Agregar  libro 
Titulo: 


Autores: 


Q.  Filtro 


Editor: 

Fecha 

publicacion: 

Portada: 


| Browse-  I No  file  selected. 


todos  o 


cj  > SB  3\  & ft  = 


Imagen  6-19.  El  formulario  para  editar,  despues  de  agregar  “rawjdjields” 
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&Y  ahora  como  escribo  en  esa  caja? 


La  base  de  datos  identifica  a cada  editor  con  un  ID  (una  clave  primaria).  Dado  que  los 
seres  humanos  no  memorizamos  normalmente  identificadores  (ID)  de  las  base  de 
datos,  existe  un  icono  con  forma  de  lupa  que  permite,  con  un  simple  clic,  desplegar 
una  ventana  flotante,  en  la  cual  se  pueden  seleccionar  al  editor  para  agregarlo  a la 
forma.  Por  lo  que  no  necesitas  escribir  directamente  en  la  caja  el  ID  de  el  objeto. 

Personalizar  la  apariencia  de  la  interfaz  de  administracion 

Claramente,  tener  la  frase  “Administracion  de  Django”  en  la  cabecera  de  cada  pagina 
de  administracion  es  ridiculo.  Es  solo  un  texto  de  relleno  que  es  facil  de  cambiar, 
usando  el  sistema  de  plantillas  de  Django.  El  sitio  de  administracion  de  Django  esta 
propulsado  por  el  mismo 

Django,  sus  interfaces  usan  el  sistema  de  plantillas  propio  de  Django.  (El  sistema  de 
plantillas  de  Django  fue  presentado  en  el  capitulo4.) 

Como  explicamos  en  el  Capltulo4,  la  configuracion  de  TEMPLATE_DIRS  especifica 
una  lista  de  directorios  a verificar  cuando  se  cargan  plantillas  Django.  Para 
personalizar  las  plantillas  del  sitio  de  administracion,  simplemente  copia  el  conjunto 
relevante  de  plantillas  de  la  distribution  Django  en  uno  de  los  directorios  apuntados 
porTEMPLATEJDIRS. 

El  sitio  de  administracion  muestra  “Administracion  de  Django”  en  la  cabecera 
porque  esto  es  lo  que  se  incluye  en  la  plantilla  admin/base_site.html.  Por  defecto, 
esta  plantilla  se  encuentra  en  el  directorio  de  plantillas  de  administracion  de  Django, 
django/contrib/admin/templates,  que  puedes  encontrar  buscando  en  tu  directorio 
site-packages  de  Python,  o donde  sea  que  Django  fue  instalado.  Para  personalizar 
esta  plantilla  base_site.html,  copia  la  original  dentro  de  un  subdirectorio  llamado 
admin  dentro  de  cualquier  directorio  que  este  usando  TEMPLATE_DIRS.  Por 
ejemplo,  si  tu  directorio  TEMPLATE_DIRS  incluye  "/home/misplantillas",  entonces 
copia  django/contrib/admin/templates/admin/base_site.html  al  directorio 
/home/misplantillas/admin/base_site.html.  No  te  olvides  del  subdirectorio  admin. 

Luego,  solo  edita  el  nuevo  archivo  admin/base_site.html  para  reemplazar  el  texto 
generico  de  Django,  por  el  nombre  de  tu  propio  sitio,  tal  como  lo  quieres  ver. 

Nota  que  cualquier  plantilla  por  defecto  de  Django  Admin  puede  ser  reescrita.  Para 
reescribir  una  plantilla,  haz  lo  mismo  que  hicimos  con  base_site.html:  copia  esta 
desde  el  directorio  original  a tu  directorio  personalizado  y haz  los  cambios  sobre  esta 
copia. 

Puede  que  te  preguntes  como,  si  TEMPLATE_DIRS  estaba  vacio  al  principio, 
Django  encuentra  las  plantillas  por  defecto  de  la  interfaz  de  administracion.  La 
respuesta  es  que,  por  defecto,  Django  automaticamente  busca  plantillas  dentro  del 
subdirectorio  templates/  de  cada  paquete  de  aplicacion  como  alternativa.  Mira 
capitulo  10  para  obtener  mas  information  sobre  como  funciona  esto. 

Personalizar  la  pagina  indice  del  administrador 

En  una  nota  similar,  puedes  tener  la  intention  de  personalizar  la  apariencia  (el  look& 
feel)  de  la  pagina  principal  del  administrador.  Por  defecto,  aqui  se  muestran  todas  las 
aplicaciones,  de  acuerdo  a la  configuracion  que  tenga  INSTALLED_APPS,  ordenados 
por  el  nombre  de  la  aplicacion.  Quizas  quieras,  por  ejemplo,  cambiar  el  orden  para 
hacer  mas  facil  ubicar  determinada  aplicacion  que  estas  buscando.  Despues  de  todo, 
la  pagina  inicial  es  probablemente  la  mas  importante  de  la  interfaz  de 
administracion,  y deberia  ser  facil  utilizarla. 

La  plantilla  para  personalizarla  es  admin/index. html.  (Recuerda  copiar 
admin/index.html  a tu  directorio  de  plantillas  propio  como  en  el  ejemplo  previo). 
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Edita  el  archivo,  y veras  que  usa  una  etiqueta  llamada  {%  get_admin_app_list  as 
appjist  %}.  Esta  etiqueta  devuelve  todas  las  aplicaciones  Django  instaladas.  En  vez 
de  usar  esta  etiqueta,  puedes  incluir  vinculos  explicitos  a objetos  especificos  de  la 
manera  que  creas  mas  conveniente.  Si  el  codigo  explicito  en  una  plantilla  no  te 
satisface,  puedes  ver  el  Capitulo  10  para  encontrar  detalles  sobre  como  implementar 
tus  propias  etiquetas  de  plantillas. 

Para  detalles  completos  sobre  la  personalization  del  sitio  de  administracion  de 
Django,  mira  el  Capitulo  17. 

Usuarios,  Grupos  y Permisos 

Desde  que  estas  identificado  como  un  superusuario,  tienes  acceso  a crear,  editar  y 
eliminar  cualquier  objeto.  Sin  embargo,  la  interfaz  de  administracion  tiene  un 
sistema  de  permisos  de  usuario  que  puedes  usar  para  darles  a otros  usuarios  acceso 
limitado  a las  partes  de  la  interfaz  que  ellos  necesitan. 

Puedes  editar  estos  usuarios  y permisos  a traves  de  la  interfaz  de  administracion, 
como  si  fuese  cualquier  otro  objeto.  Los  vinculos  a los  modelos  Usuarios  y Grupos  se 
encuentran  en  el  indice  de  la  pagina  principal  junto  con  todo  el  resto  de  los  modelos 
que  haz  definido. 

Los  objetos  usuario  tienen  campos  estandar:  nombre  de  usuario,  contrasena, 
direction  de  correo,  y nombre  real  que  puedes  esperar,  seguidos  de  un  conjunto  de 
campos  que  deflnen  lo  que  el  usuario  tiene  permitido  hacer  en  la  interfaz  de 
administracion.  Primero,  hay  un  conjunto  de  tres  opciones  seleccionables: 

■ La  opcion  Activo  define  si  el  usuario  esta  activo  en  todo  sentido.  Si  esta 
desactivada,  el  usuario  no  tendra  acceso  a ninguna  URL  que  requiera 
identification. 

■ La  opcion  Es  staff  indica  que  el  usuario  esta  habilitado  a ingresar  a la  interfaz 
de  administracion  (por  ejemplo,  indica  que  el  usuario  es  considerado  un 
miembro  del  staff  en  tu  organization).  Como  el  mismo  sistema  de  usuarios 
puede  usarse  para  controlar  el  acceso  al  sitio  publico  (es  decir,  sitios 
restringidos  no  administrativos.  Mira  el  capitulo  12.),  esta  opcion  diferencia 
entre  usuarios  publicos  y administradores. 

■ La  opcion  es  superusuario  da  al  usuario  completo  e irrestricto  acceso  a todos 
los  elementos  de  la  interfaz  de  administracion,  y sus  permisos  regulares  son 
ignorados. 


Permisos 


(7]  Activo 

Indica  si  el  usuario  debe  ser  tratado  como  un  usuario  activo.  Desactive  este  campo  en  lugar  de  eliminar  usuarios. 

(7]  Es  staff 

Indica  si  el  usuario  puede  ingresar  a este  sitio  de  administracion. 

[7]  Es  superusuario 

Indica  que  este  usuario  posee  todos  los  permisos  sin  que  sea  necesario  asignarle  los  mismos  en  forma  explicita. 


Imagen  6-20.  Tipos  de  permisos. 

Los  administradores  “normales”  - esto  es,  activos,  no  superusuarios  y miembros 
del  staff  - tienen  accesos  que  dependen  del  conjunto  de  permisos  concedidos.  Cada 
objeto  editable  a traves  de  la  interfaz  de  administracion  tiene  tres  permisos:  un 
permiso  de  crear,  un  permiso  de  modi  Hear  y un  permiso  de  eliminar.  Logicamente, 
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asignando  permisos  a un  usuario  habilitas  que  este  acceda  a realizar  la  accion  que  el 
permiso  describe. 


Nota  El  acceso  a editar  usuarios  y permisos  tambien  es  controlado  por  el  sistema 
de  permisos.  Si  le  das  a alguien  el  permiso  de  editar  usuarios,  jestara  en  condiciones 
de  editar  sus  propios  permisos,  que  probablemente  no  es  lo  que  querias! 

Tambien  puedes  asignar  usuarios  a grupos.  Un  grupo  es  simplemente  un  conjunto 
de  permisos  a aplicar  a todos  los  usuarios  de  ese  grupo.  Los  grupos  son  utiles  para 
otorgar  identicos  permisos  a un  gran  numero  de  usuarios. 


Permisos  de 
usuario: 


Specific  permissions  for  this  user.  Mantenga  presionada  "Control",  o 

Disponible  permisos  de  usuario  Q 

^ Filtro 


permisos  de  usuario  seleccionados 


auth  | usuario  | Can  add  user 

auth  | usuario  | Can  change  user 

auth  j usuario  j Can  delete  user 

biblioteca  | autor  | Can  add  autor 

biblioteca  j autor  j Can  change  autor 

biblioteca  | autor  | Can  delete  autor 

biblioteca  j editor  | Can  add  editor 

biblioteca  j editor  j Can  change  editor 

biblioteca  j editor  j Can  delete  editor 

biblioteca  j libro  | Can  add  libro 

biblioteca  j libro  j Can  change  libro 

biblioteca  | libro  | Can  delete  libro 

contenttypes  | tipo  de  contenido  | Can  add  content  type 

contenttypes  j tipo  de  contenido  | Can  change  content  type 

Seleccionar  todos  0 


1° 
1 0 


0 Eliminar  todos 


Imagen  6-21.  Asignar  permisos. 


Cuando  y porque  usar  la  interfaz  de  administracion 

Pensamos  que  la  interfaz  de  administracion  de  Django  es  bastante  espectacular.  De 
hecho,  diriamos  que  es  una  de  sus  killer  feautures , o sea,  una  de  sus  caracteristicas 
sobresalientes.  Sin  embargo,  a menudo  nos  preguntan  sobre  “casos  de  uso”  para  la 
interfaz  de  administracion  Cuando  debemos  usarlo  y por  que?).  A lo  largo  de  los 
anos,  hemos  descubierto  algunos  patrones  donde  pensamos  que  usar  la  interfaz  de 
administracion  resulta  util. 

Obviamente,  es  muy  util  para  modiflcar  datos  (se  vela  venir).  Si  tenemos  cualquier 
tipo  de  tarea  de  introduction  de  datos,  el  administrador  es  dificil  de  superar. 
Sospechamos  que  la  gran  mayoria  de  lectores  de  este  libro  tiene  una  horda  de  tareas 
de  este  tipo. 

La  interfaz  de  administracion  de  Django  brilla  especialmente  cuando  usuarios  no 
tecnicos  necesitan  ser  capaces  de  ingresar  datos;  ese  es  el  proposito  detras  de  esta 
caracteristica,  despues  de  todo.  En  el  periodico  donde  Django  fue  creado 
originalmente,  el  desarrollo  de  una  caracteristica  tipica  online  - un  reporte  especial 
sobre  la  calidad  del  agua  del  acueducto  municipal,  supongamos  - implicaba  algo  asi: 

■ El  periodista  responsable  del  articulo  se  reune  con  uno  de  los  desarrolladores 
y discuten  sobre  la  informacion  disponible. 

■ El  desarrollador  disena  un  modelo  basado  en  esta  informacion  y luego  abre  la 
interfaz  de  administracion  para  el  periodista. 

■ Mientras  el  periodista  ingresa  datos  a Django,  el  programador  puede 
enfocarse  en  desarrollar  la  interfaz  accesible  publicamente  (;la  parte 
divertida!) . 
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En  otras  palabras,  la  razon  de  ser  de  la  interfaz  de  administration  de  Django  es 
facilitar  el  trabajo  simultaneo  de  productores  de  contenido  y programadores. 

Sin  embargo,  mas  alia  de  estas  tareas  de  entrada  de  datos  obvias,  encontramos  que 
la  interfaz  de  administration  es  util  en  algunos  otros  casos: 

■ Inspeccionar  modelos  de  datos.  La  primer  cosa  que  hacemos  cuando  hemos 
definido  un  nuevo  modelo  es  llamarlo  desde  la  interfaz  de  administracion  e 
ingresar  algunos  datos  de  relleno.  Esto  es  usual  para  encontrar  errores  de 
modelado;  tener  una  interfaz  graflca  al  modelo  revela  problemas 
rapidamente. 

■ Gestion  de  datos  adquiridos.  Elay  una  pequena  entrada  de  datos  asociada  a un 
sitio  como  http://chicagocrime.org,  puesto  que  la  mayoria  de  los  datos 
provienen  de  una  fuente  automatica.  No  obstante,  cuando  surgen  problemas 
con  los  datos  automaticos,  es  util  poder  entrar  y editarlos  facilmente. 

<?,Que  sigue? 

Elasta  ahora  hemos  creado  algunos  modelos  y hemos  conflgurando  una  interfaz 
administrativa  de  primera  clase  para  modificar  los  datos.  En  el  proximo  capitulo,  nos 
meteremos  de  lleno  en  el  Desarrollo  Web:  creando  y procesando  formularios. 
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Procesamiento  de  formularios 


Los  formularios  en  HTML,  son  la  columns  vertebral  de  los  sitios  Web  interactivos, 
os  encontramos  como  simples  caja  de  busquedas  como  los  que  usa  Google  o como 
los  inconfundibles  formularios  para  subir  comentarios  siempre  presentes  en  la 
mayorfa  de  blogs,  pero  tambien  existen  complejas  interfaces  que  permiten  la 
entradas  de  datos  interactivamente  y de  forma  personalizada,  y es  que  los 
formularios  son  una  necesidad  basica  en  la  mayoria  de  aplicaciones  Web  modernas 
que  necesitan  recopilar  datos  a traves  de  internet. 

Este  capitulo  cubre  la  manera  de  usar  Django  para  recopilar  datos  a traves  de 
formularios,  validarlos  y hacer  algo  util  con  ellos.  A lo  largo  de  este  capitulo  nos 
enfocaremos  en  conocer  los  objetos  HttpRequest  y los  objetos  Form 

Comenzaremos  creando  un  simple  formulario  de  busquedas  “a  mano”, 
observando  como  manejar  los  datos  suministrados  al  navegador.  Y a partir  de  ahi, 
pasaremos  al  uso  del  framework  de  formularios  que  viene  incluido  en  Django. 


Obteniendo  datos  de  los  objetos  “Request” 

Introducimos  los  objetos  HttpRequest  en  el  capitulo  3,  cuando  cubrimos  las 
funciones  vista,  pero  no  tuvimos  mucho  que  decir  acerca  de  ellos  en  aquel  momento. 

Recuerdas  que  cada  funcion  de  vista  toma  un  objeto  HttpRequest  como  primer 
parametro,  tal  como  en  la  vista  hola()  que  construimos: 

from  django.http  import  HttpResponse 

def  hola(request): 

return  HttpResponse("Hola  mundo") 


Los  objetos  HttpRequest,  tal  como  la  variable  request,  contienen  un  numero  de 
atributos  y metodos  interesantes  con  los  cuales  deberias  familiarizarte,  a fin  de  saber 
como  utilizarlos  lo  mejor  posible.  Puedes  utilizar  estos  atributos  para  conseguir 
informacion  acerca  de  las  peticiones  que  recibes  (por  ejemplo:  el  usuario  o el 
navegador  que  esta  cargando  la  pagina  en  tu  sitio  creado  con  Django),  al  mismo 
tiempo  que  la  funcion  vista  es  ejecutada. 


INFORMACION  ACERCA  DE  LAS  URL 

Los  objetos  HttpRequest  contienen  algunas  piezas  de  informacion  acerca  de  la  URL 
requerida. 

La  siguiente  tabla  muestra  los  metodos  o atributos  de  las  peticiones  request: 
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Atributos  o Metodos 


Descripcion 


Ejemplo 


request.path 


request.get_host() 
request.get_Ml_path() 
request.is_secure  () 


La  ruta  completa,  no  incluye  el 
dominio  pero  incluye,  la  barra 
inclinada. 

El  host  (ejemplo:  tu  “dominio,”  en 
lenguaje  comun). 

La  ruta  (path),  mas  una  cadena  de 
consulta  (si  esta  disponible). 

True  si  la  peticion  fue  hecha  via 
HTTPS.  Si  no,  False. 


"/hola/" 


"127.0.0.1:8000"  o 
"www.example.com" 

" /hola/?print=true" 

True  o False 


Tabla  7.1  Informacion  acerca  de  las  URL 


Siempre  usa  estos  atributos/metodos  en  lugar  de  incrustar  las  URLs  en  tus  vistas, 
esto  hace  mas  flexible  tu  codigo  y mas  facil  de  usar  en  otros  lugares  u otras 
aplicaciones.  Un  simple  ejemplo: 

# j Mai ! % 

def  vista_actual_url(request): 

return  HttpResponse('Bienvenido  a mi  pagina  en  /pagina_actual/M) 

# Bien  © 

def  vista_actual_url(request): 

return  HttpResponse("bienvenido  a mi  pagina  en  %s"  % request.path) 


mAs  informacion  acerca  de  las  peticiones  o request 

request.META  es  un  diccionario  Python,  que  contiene  todas  las  cabeceras  HTTP 
disponibles  para  la  peticion  dada  -Incluyendo  la  direccion  IP  y el  agente- 
Generalmente  el  nombre  y la  version  del  navegador  Web.  Observa  que  la  lista 
completa  de  cabeceras  disponibles  depende  de  las  cabeceras  que  el  usuario  envra  y 
las  cabeceras  que  el  servidor  Web  seleccione.  Algunas  de  las  claves  mas  comunes 
estan  disponibles  como  diccionarios  y son  las  siguientes: 

■ HTTP_REFERER:  La  respectiva  URL,  a la  que  se  hace  referencia.  (Observa  la 
forma  en  que  se  escribe  REFERER.) 

■ HTTP_USER_AGENT:  El  navegador  del  usuario  en  forma  de  cadena, 
cualquiera  que  sea.  Esta  es  algo  si:  "Mozilla/5.0  (XI 1;  U;  Linux  i686;  fr-FR;  rv: 
1.8.1.17)  Gecko/20080829  Firefox/2.0.0.17". 

■ REMOTE_ADDR:  La  direccion  IP  del  cliente,  por  ejemplo:  "12.345.67.89".  (Si 
la  peticion  ha  pasado  a traves  de  un  proxi,  entonces  puede  retornar  una  lista 
separada  por  comas,  conteniendo  las  direcciones  IP,  por  ejemplo: 
"12.345.67.89,  23.456.78.90".) 

Observa  que  request.META  es  basicamente  un  diccionario  Python,  que  contiene 
todas  las  cabeceras  HTTP  disponibles,  las  que  dependen  del  navegador  y del  servidor 
que  se  este  usando  en  ese  determinado  momento,  por  lo  que  obtendras  una 
exception  KeyError  si  intentas  acceder  a una  clave  que  no  existe.  (Ademas  las 
cabeceras  HTTP  son  datos  externos  - que  son  subidos  por  los  navegadores  de  los 
usuarios,  por  lo  que  no  deberias  confiar  en  ellos,  asi  que  siempre  disena  tus 
aplicaciones  para  que  fallen  intencionalmente,  si  una  cabecera  en  particular  esta 
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vacia  o no  existe.)  Aprende  a usar  las  clausulas  try/except  o el  metodo  get()  para 
manejar  los  casos  en  que  alguna  de  estas  claves  esten  indefinidas,  para  evitar  errores: 

# j Mai ! % 

def  mostrar_navegador(request): 

ua  = request. META['HTTP_USER_AGENT']  # jPodrla  lanzar:  KeyError! 
return  HttpResponse("Tu  navegador  es  %s"  % ua) 

# Bien  (Version  1) 

def  mostrar_navegador(request): 
try: 

ua  = request.  META['HTTP_USER_AG  ENT] 
except  KeyError: 
ua  = 'unknown' 

return  HttpResponse("Tu  navegador  es  %s"  % ua) 

# Bien  (Version  2) 

def  mostrar_navegador2(request): 

ua  = request. META. get('HTTP_USER_AGENT',  'unknown') 
return  HttpResponse("Tu  navegador  es  %s"  % ua) 

Te  animamos  a escribir  pequenas  vistas  como  estas,  que  muestren  todos  los  datos 
request.META,  que  puedas  conseguir  para  familiarizarte  con  los  conceptos.  La  vista 
puede  empezar  asi: 

def  atributos_meta(request): 
valor  = request. META. items() 
valor. sort() 
html  = [] 
for  k,  v in  valor: 

html.append('<tr><td>%s</td><td>%s</td></tr>'  % (k,  v)) 
return  HttpResponse('<table>%s</table>'  % '\n'.join(html)) 

Como  ejercicio  trata  de  convertir  la  vista  anterior,  para  que  use  el  sistema  de 
plantillas  en  lugar  de  incrustar  el  codigo  HTML  en  la  vista.  Tambien  trata  de  agregar 
request.path  y los  otros  metodos  HttpRequest  que  vimos  en  la  section  anterior. 

INFORMACION  ACERCA  DE  LOS  DATOS  RECIBIDOS 

Mas  alia  de  los  metadatas  basicos  obtenidos  de  las  peticiones  Web,  los  objetos 
HttpRequest  poseen  dos  atributos  mas,  que  contienen  information  recibida  de  los 
usuarios:  request.GET  y request.POST.  Ambos  atributos  son  como  objetos  tipo 
diccionarios  que  permiten  el  acceso  a datos  GET  y POST 


OBJETOS  COMO  DICCIONARIOS? 


Cuando  decimos  que  request.GET  y requestPOST  son  como  objetos  tipo  diccionario 
(“dictionary-like”),  lo  que  tratamos  de  decirte  es  que  se  comportan  como 
diccionarios  estandar  de  Python,  pero  tecnicamente  en  el  fondo  no  son  diccionarios. 
Por  ejemplo  request.GET  y request.POST  contienen  ambos,  metodos  como  get(), 
keys()  y values!),  por  lo  que  puede  iterarse  sobre  sus  claves  usando  un  bucle  como: 
for  key  in  request.GET. 

^Entonces  porque  la  distincion?  bueno,  porque  ambos  request.GET  y request.POST 
contienen  metodos  adicionales,  que  los  diccionarios  normales  no,  llegaremos  a eso 
dentro  de  poco. 


128 


CAPITULO  7 FORMULARIOS 


Puede  ser  que  encuentres  el  termino  similar  a “file-like  objects”  - Objetos  Python 
que  contienen  algunos  metodos  basicos  como  readQ,  lo  que  le  permite  actuar  a un 
determinado  archivo  como  un  “objeto”. 

Los  datos  POST  generalmente  son  recibidos  de  formularios  (<form>)  HTML, 
mientras  que  los  datos  GET  son  enviados  a los  formularios  (<form>)  o mediante  una 
cadena  de  consulta  a una  pagina  URL. 

Tu  primer  formulario  creado  con  Django 

Continuando  con  el  ejemplo  en  curso  sobre:  libros,  autores  y editores,  vamos  a crear 
un  formulario,  mediante  una  vista  muy  simple  que  permita  a los  usuarios  buscar 
libros  en  la  base  de  datos  mediante  el  titulo. 

Generalmente,  se  necesitan  dos  partes  para  desarrollar  un  formulario:  la  interfaz 
de  usuario  en  HTML  y la  vista  que  procesa  los  datos  obtenidos  o subidos  por  los 
usuarios.  La  primera  parte  es  sencilla;  solo  necesitamos  crear  una  vista  que  muestre 
el  formulario  de  busqueda: 


biblioteca/views .py 


from  django. shortcuts  import  render 

def  formulario_buscar(request): 

return  render(request,  'formulario_buscar.html') 

Tal  como  aprendimos  en  el  capitulo  3,  la  vista  puede  estar  en  cualquier  lugar  de  la 
ruta  de  busqueda  de  Python.  Pero  por  convention  este  debe  de  ir  en  una  vista, 
podemos  colocarla  en  biblioteca/views. py. 

Acompanada  de  una  plantilla  llamada  formulario_buscar.html,  que  debe  ubicarse 
en  un  directorio  llamado  templates  (de  forma  predeterminada  Django  busca  las 
plantillas  en  un  directorio  interno  llamado  template  en  cada  aplicacion  registrada), 
dentro  del  directorio  de  la  aplicacion  biblioteca,  en  el  mismo  nivel  que  el  directorio 
migrations: 


biblioteca/ templates /formulario_buscar . html 


<html> 

<head> 

<title>Buscar</title> 

</head> 

<body> 

<form  action- ’/buscar/"  method="get"> 

<input  type- ’text”  name="q"> 

<input  type="submit"  value="Buscar"> 

</form> 

</body> 

</html> 

Y para  acceder  al  formulario,  necesitamos  el  patron  para  la  URL: 


misitio/urls .py 


from  biblioteca  import  views 

urlpatterns  = [ 

# ... 

url(r'Aformulario-buscar/$',  views. formulario_buscar), 


] 
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(Observa  que  hemos  importando  el  modulo  views  directamente,  en  lugar  de  hacer 
algo  como  esto:  from  biblioteca. views  import  formulario_buscar,  porque  lo  anterior 
es  mas  elegante  y entendible. 

Veremos  la  forma  de  aprovechar  este  tipo  de  importaciones  en  mas  detalle,  en  el 
capitulo  8. 

Ahora,  ejecuta  el  comando  python  manage. py  runserver  o recarga  el  servidor  y 
visita  lapagina:  http:// 127. 0.0.1:8000/formulario-buscar/,  donde  veras  una  interfaz 
de  busqueda,  bastante  simple,  construida  mediante  un  sencillo  formulario: 

^ I®  127.0.01:8000/formulario-buscar/  ""  C j ^ ^ \ ■ft'  “ 

| Buscar  | 


Figura  7-1.  Ejemplo  de  un  formulario  de  busquedas. 

Trata  de  subir  el  formulario,  y solo  conseguiras  un  error  404.  El  formulario  que 
apunta  a la  URL  /buscar/,  aun  no  ha  sido  implementado.  Reparemos  eso  con  una 
segunda  funcion  de  vista  y su  respectiva  URLconf: 


misitio/urls .py 


urlpatterns  = [ 

# ... 

url(r'Aformulario-buscar/$',  views.formulario_buscar), 
url(r'Abuscar/$',  views. buscar), 

# ... 

] 


biblioteca/views .py 


from  django.http  import  HttpResponse 
def  buscar(request): 

if  'q  in  request. GET  and  request.GET['q']: 

mensaje  = ’Estas  buscando:  %r'  % request. GET['q'] 

else: 

mensaje  = 'Haz  subido  un  formulario  vacio.' 

return  HttpResponse(mensaje) 

Por  el  momento,  esto  exhibe  meramente  el  termino  de  busqueda  del  usuario,  asi 
que  podemos  estar  seguros  de  una  cosa,  los  datos  estan  siendo  enviados  a Django 
correctamente,  y puede  darnos  una  ligera  perception  sobre  la  forma  en  que  el 
termino  de  busqueda  atraviesa  el  sistema. 

En  resumen: 

■ El  formulario  HTML  (<form>)  define  una  variable  q.  Cuando  esta  es  subida  el 
valor  de  q es  enviado  mediante  el  metodo  GET  a la  URL  /buscar/. 

■ La  vista  de  Django  maneja  la  URL  /buscar/  y tiene  acceso  al  valor  de  q en  la 
petition  request.  GET. 
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Una  cosa  que  es  importante  precisar  aqui,  es  que  explicitamente  verificamos 
que  'q'  exista  en  request.GET.  Como  precisamos  en  la  seccion  anterior  con  las 
peticiones  request.META,  no  deberias  confiar  en  nada  que  sea  subido  por  los 
usuarios  o incluso  asume  que  no  subieron  nada  en  primer  lugar.  Si  no  agregas 
esta  verification,  los  formularios  vacios  lanzaran  un  error  del  tipo  KeyError  en 
la  vista: 

# MAL!  % 

d ef  b u scar_n o_h  ag  as_esto (request): 

#jl_as  siguientes  lineas  lanzan  un  error  "KeyError"  si  no  se  envia  'q'! 

mensaje  = 'Estas  buscando:  %r'  % request. GET['q'] 
return  HttpResponse(mensaje) 


parAmetros  de  cadenas  de  consulta 


Porque  los  datos  GET  se  pasan  en  cadenas  de  consultas  (por  ejemplo: 
/buscar/?q=django)  puedes  usar  request.GET  para  acceder  a las  variables  de  las 
cadenas  de  consulta.  En  el  capitulo  3,  “Introduction  a los  patrones  URLconfs  de 
Django”,  comparamos  las  URL  bonitas  contra  las  tradicionales  URLs  de  PHP/Java  tal 
como  /tiempo/mas?horas=3  y dijimos  que  te  mostrariamos  como  hacerlo  mas 
adelante  en  el  capitulo  7.  Ahora  ya  sabes  como  acceder  a cadenas  de  parametros  en 
las  vistas  (tal  como  el  ejemplo  horas=3)  -Solo  usa  request.GET. 

Los  datos  POST  trabajan  de  la  misma  forma  que  lo  datos  GET  - solo  usa 
request.POST  en  lugar  de  request.GET. 

jEntonces  cual  es  la  diferencia  entre  GET  y POST?  Usa  GET  cuando  el  acto  de 
subir  un  formulario  solo  sea  para  “pedir”  datos.  En  cambio  usa  POST  siempre  que  el 
acto  de  subir  el  formulario  tenga  efectos  secundarios  - cambiando  datos,  enviando 
un  e-mail  o algo  que  vaya  mas  alia  de  simplemente  mostrar&dXos.  En  el  ejemplo  de 
busquedas  del  ejemplo,  estamos  usando  GET  porque  la  consulta  no  cambia  ningun 
dato  en  nuestro  servidor. 

(Consulta  http://www.w3.org/2001/tag/doc/whenToUseGet.html  si  quieres 
aprender  mas  sobre  las  peticiones  GET  and  POST.) 

Ahora  que  hemos  verificado  que  el  metodo  request.GET  es  pasado 
apropiadamente,  anclemos  la  consulta  de  busquedas  a la  base  de  datos.  (Otra  vez  en 
views.py  y rescribamos  la  funcion  buscar): 


biblioteca/views .py 


from  django.http  import  HttpResponse 
from  django. shortcuts  import  render 

from  biblioteca.models  import  Libro 

def  buscar(request): 

if  'q  in  request.GET  and  request. GET['q']: 
q = request.GET['q'] 

libros  = Libro. objects. filter(titulo icontains=q) 

return  render(request,  'resultados.html',  {'libros':  libros,  'query':  q}) 

else: 

return  HttpResponse('Por  favor  introduce  un  termino  de  busqueda.') 
Un  par  de  notas  sobre  lo  que  hicimos: 
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■ Aparte  de  checar  que  'q'  exista  en  request.GET,  nos  aseguramos  que 
request.GET['q']  no  sea  una  cadena  vatia  antes  de  pasarle  la  consulta  a la  base 
de  datos. 

■ Estamos  usando  Libro. objects. filter(titulo icontains=q)  para  consultar  en  la 

tabla  libros,  todos  los  libros  que  incluyan  en  el  titulo  los  datos  proporcionados 
en  la  consulta,  icontains  es  un  tipo  de  busqueda  (como  explicamos  en  el 
capltulo  5 y el  apendice  B)  en  la  que  no  se  distinguen  mayusculas  de 
minusculas  ( case-insensitive ■),  y que  internamente  usa  el  operador  LIKE  de 
SQL  en  la  base  de  datos.  La  declaration  puede  ser  traducida  como  “Obtener 
todos  los  libros  que  contengan  estas  palabras" 

Esta  es  una  forma  muy  simple  para  buscar  libros.  No  recomendamos  usar  una 
simple  consulta  icontains  en  bases  de  datos  muy  grandes  en  production  ya 
que  esto  puede  ser  muy  lento.  (En  el  mundo  real,  es  mejor  usar  un  sistema  de 
busqueda  personalizado  de  cierto  tipo.  Busca  en  la  Web  proyectos  libres  de 
sistemas  de  busquedas  de  lexlo  para  que  te  des  una  idea  de  las  posibilidades.) 

Pasamos  libros,  como  una  lista  de  objetos  Libro  a la  plantilla.  El  codigo  de  la 
plantilla  resultados.html  debe  incluir  algo  como  esto: 


biblioteca/templates/resultados . html 


<p>Estas  buscado:  <strong>{{  query  }}</strongx/p> 

{%  if  libros  %} 

<p>Libros  encontrados:  { libros|length  libroj  libros|pluralize  ,</p> 

<ul> 

{%  for  libros  in  libros  %} 

<li>{{  libros.titulo  }}</li> 

{%  endfor  %} 

</ul> 

{%  else  %} 

<p>Ningun  libro  coincide  con  el  criterio  de  busqueda. </p> 

{%  endif  %} 

Observa  que  estamos  usando  el  filtro  de  plantillas  pluralize,  el  cual 
apropiadamente  agrega  en  la  salida  el  plural  (la  “s”),  basado  en  el  numero  de  libros 
encontrados  en  la  base  de  datos. 

Mejorando  la  forma  de  manejar  un  formulario 

En  los  parrafos  anteriores  te  mostramos  la  forma  mas  simple  en  la  que  podrfa 
trabajar  un  formulario.  Ahora  te  mostraremos  algunos  problemas  que  pueden  surgir 
y la  manera  de  solucionarlos. 

Primero,  la  forma  en  que  la  vista  buscarQ  maneja  las  consultas  vatias  es  pobre  - 
solo  mostramos  un  mensaje  "Por  favor  introduce  un  termino  de  busqueda."  lo  que 
requiere  que  el  usuario,  tenga  que  dar  clic  de  nuevo  en  el  boton  para  regresar  su 
navegador  a la  pagina  de  busquedas.  Esto  es  horrible  y poco  profesional,  si 
implementas  algo  asl,  tus  privilegios  Django  seran  revocados. 

Seria  mucho  mejor  volver  a mostrar  el  formulario  con  los  errores  resaltados,  para 
que  el  usuario  pueda  intentar  nuevamente  rellenarlo.  La  forma  mas  facil  de  hacer 
esto,  es  renderizando  la  plantilla  otra  vez,  usando  una  clausula  else;  asf: 
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biblioteca/views .py 


from  django.http  import  HttpResponse 
from  django. shortcuts  import  render 

from  biblioteca.models  import  Libro 

def  formulario_buscar(request): 

return  render(request,  ’formulario_buscar.htmr) 

def  buscar(request): 

if 'q  in  request. GET  and  request. GET['q']: 
q = request.GET['q'] 

libros  = Libro. objects. filter(titulo icontains=q) 

return  render(request,  'resultados.html', {'libras':  libros,  'query':  q}) 

else: 

return  render(request,  'formulario_buscar.htmr,  {'error':  True}) 

(Observa  que  hemos  incluido  la  vista  formulario_buscarO,  para  que  puedas 
observar  ambas  vistas  en  un  solo  lugar.) 

Tambien  hemos  mejorado  la  vista  buscar()  para  renderizar  la  plantilla 
resultados.html  otra  vez,  si  la  consulta  esta  vacia.  Ya  que  necesitamos  mostrar  los 
mensajes  de  errores  en  la  plantilla,  hemos  pasado  la  variable  error  a la  plantilla. 
Ahora  edita  formulario_tmscar.html  y checa  la  variable  error  que  hemos  agregado: 


biblioteca/templates/formulario_buscar . html 


<html> 

<head> 

<title>Buscar</title> 

</head> 

<body> 

{%  if  error  %} 

<p  style="color:  red;">Por  favor  introduce  un  termino  de  busqueda.</p> 

{%  endif  %} 

<form  action="/buscar/"  method="get"> 

<input  type- 'text"  name="q"> 

<input  type="submit"  value="Buscar"> 

</form> 

</body> 

</html> 

Con  este  cambio  en  su  lugar,  tenemos  una  mejor  aplicacion,  pero  ahora  nos 
preguntamos  ^Es  realmente  necesaria  una  vista  dedicada  como  formulario_buscar(), 
para  realizar  este  proceso?  Tal  y como  estan  las  cosas,  una  petition  a una  URL 
/buscar/  (http:// 127. 0.0.1:8000/buscar/,  sin  parametros  GET)  mostrara  un 
formulario  vacio  (mostrandonos  el  mensaje  de  error).  Podemos  remover  la  vista 
formulario_buscar(),  junto  con  los  patrones  asociados  a la  URL,  asi  como 
necesitamos  cambiar  la  vista  buscar()  para  que  esconda  el  mensaje  de  error  cuando 
alguien  visite  /buscar/  sin  parametros  GET: 
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biblioteca/views .py 


def  buscar(request): 
error  = False 
if  'q  in  request. GET: 
q = request.GET['q'] 
if  not  q: 
error  = True 
else: 

libros  = Libro.  objects.  filter(titulo icontains=q) 

return  render(request,  'resultados.html',  {'libros':  libros,  'query':  q}) 

return  render(request,  'formulario_buscar.html',  {'error':  error}) 

Con  esta  vista  actualizada,  cuando  un  usuario  visita  /buscar/  sin  parametros  GET, 
el  formulario  de  busqueda  no  mostrara  los  mensajes  de  error.  Si  un  usuario  trata  de 
subir  un  formulario  con  un  valor  vacio  para  'q',  el  formulario  de  busqueda  mostrara 
el  mensaje  de  error  en  letras  rojas.  Y flnalmente  si  un  usuario  sube  un  formulario  con 
una  cadena  de  consulta  - es  decir  con  valores  no  vacios  para  'q',  se  mostraran  los 
resultados  de  la  busqueda. 

Podemos  realizar  una  mejora  final  para  nuestra  aplicacion,  removiendo  un  poco 
de  redundancia.  Ahora  que  hemos  comenzado  a refinar  las  dos  vistas  y las  URLs  en 
una  sola  llamada  /buscar/,  que  manejara  el  despliegue  y el  formulario  de  busquedas 
y tambien  mostrara  los  resultados,  por  lo  que  el  formulario  en  HTML  en  la  plantilla 
formulario_buscar.html  no  necesita  que  se  incruste  el  codigo  en  la  URL,  en  lugar  de 
usar  esto: 

<form  action="/buscar/"  method="get"> 

Podemos  cambiarlo  por  esto: 

<form  action-'"  method="get"> 

action=""  significa  “Envia  el  formulario  con  la  misma  URL  a la  pagina  actual”.  Con 
este  cambio  realizado,  no  tienes  que  recordar  cambiar  action  cada  vez  que  necesites 
enlazar  la  vista  buscarQ  a otra  URL. 

Validacion  simple 

Nuestro  ejemplo  de  busquedas  es  razonablemente  simple,  especificamente  hablando 
en  terminos  de  validacion  de  datos,  ya  que  solamente  nos  aseguramos  que  las 
consultas  en  las  busquedas  no  esten  vacias.  Muchos  formularios  en  HTML  incluyen 
niveles  de  validacion  mas  complejos,  que  van  mas  alia  de  solo  asegurarse  que  los 
valores  no  esten  vacios.  Todos  hemos  visto  mensajes  de  error  en  sitios  Web  como 
estos. 


■ “Por  favor  introduce  una  direccion  de  correo  electro nica  valida”.  ‘foo’  no  es 
una  direccion  de  correo  electronica. 

■ “Por  favor  introduce  un  codigo  postal  valido  de  5 digitos”.  ‘123  no  es  un 
codigo  postal  valido' 

■ “Por  favor  introduce  una  fecha  valida  en  el  formato  YYYY-MM-DD.” 

■ “Por  favor  introduce  una  contrasena  que  contenga  al  menos  8 caracteres  y 
que  contenga  al  menos  un  numero”. 
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Una  nota  sobre  validacion  usando  Java  Script 

Este  tema  va  mas  alia  del  alcance  de  este  libro,  pero  puedes  usar  Java  Script 
para  validar  datos  del  lado  del  cliente,  directamente  en  el  navegador.  Pero 
ten  cuidado:  incluso  si  haces  esto,  tambien  debes  de  validar  los  datos  del 
lado  del  servidor.  Algunas  personas  pueden  tener  Java  Script  desactivado  y 
algunos  usuarios  maliciosos  pueden  subir  en  crudo,  datos  no  validos 
directamente  al  manejador  de  formularios,  para  ver  que  danos  pueden 
causar  sus  travesuras. 

No  hay  nada  que  hacer  en  estos  casos,  con  exception  de  siempre  validar 
los  datos  enviados  por  los  usuarios  de  el  lado  del  servidor  (Por  ejemplo  en 
las  vista  de  Django).  Debes  pensar  en  usar  la  validacion  en  Java  Script 
como  una  caracteristica  extra  de  usabilidad,  no  como  la  unica  manera  de 
validacion. 


Bien,  ajustemos  la  vista  buscar()  para  que  valide  terminos  de  busqueda  que 
contengan  como  maximo  20  caracteres  o menos.  (Para  efectos  del  ejemplo,  digamos 
que  los  terminos  largos  pueden  hacer  las  consultas  muy  lentas.)  jComo  podemos 
hacer  eso?  La  cosa  mas  simple  posible  seria  pensar  en  incrustar  directamente  la 
logica  en  la  vista,  mas  o menos  asi: 


biblioteca/views .py 


def  buscar(request): 
error  = False 
if  'q  in  request. GET: 
q = request.GET['q'] 
if  not  q: 

error  = True 
elif  len(q)  > 20: 
error  = True 
else: 

libros  = Libro. objects. filter(titulo icontains=q) 

return  render(request,  resultados.html', {'libros':  libros,  query':  q}) 
return  render(request,  'formulario_buscar.html', {'error':  error}) 

Ahora,  si  tratamos  de  enviar  una  consulta  que  contenga  mas  de  20  caracteres  de 
longitud,  no  nos  permitira  buscar,  solo  obtendremos  un  mensaje  de  error.  Pero  el 
mensaje  de  error  actual  en  formulario_tmscar.html  dice:  "Por  favor  introduce  un 
termino  de  busqueda."  Por  lo  que  tendremos  que  cambiarlo  para  ser  mas  precisos: 


biblioteca/templates/formulario_buscar . html 


<html> 

<head> 

<title>Buscar</title> 

</head> 

<body> 

{%  if  error  %} 

<p  style="color:  red;">Por  favor  introduce  un  termino  de  busqueda  menor  a 
20  caracteres  </p> 

{%  endif  %} 

<form  action- Vbuscar/"  method="get"> 

<input  type="text"  name="q"> 
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<input  type-'submit"  value="Buscar"> 

</form> 

</body> 

</html> 

Hay  algo  muy  raro  en  esto.  El  unico  mensaje  de  error  es  potencialmente  confuso. 
^Por  que  el  mensaje  para  el  envio  de  un  formulario  vacio  menciona  un  limite  de  20 
caracteres?  Los  mensajes  de  error  deben  ser  especfficos,  no  deben  dar  lugar  a 
ambigiiedades  y no  deben  ser  confusos. 

El  problema  esta  en  el  hecho  de  que  estamos  usando  un  simple  valor  booleano 
para  manejar  el  error,  mientras  que  deberiamos  usar  una  lista  de  cadenas  para 
mostrar  el  mensaje  de  error.  Esta  es  la  forma  en  que  podemos  arreglarlo: 


biblioteca/views .py 


def  buscar(request): 
errors  = [] 

if  'q  in  request. GET: 
q = request.GET['q'] 
if  not  q: 

errors.append('Por  favor  introduce  un  termino  de  busqueda.') 

elif  len(q)  > 20: 

errors. append('Por  favor  introduce  un  termino  de  busqueda  menor  a 
20  caracteres.') 

else: 

libros  = Libro.  objects.  filter(titulo icontains=q) 

return  render(request,  'resultados.html', {'libros':  libros,  'query':  q}) 

return  render(request,  'formulario_buscar.html',  {'errors':  errors}) 

Ahora,  necesitamos  hacer  algunos  pequenos  cambios  a la  plantilla 
formulario_buscar.html  para  que  refleje  ahora  la  forma  en  que  estamos  pasando  la 
lista  de  errors  e n lugar  de  un  valor  booleano  error. 


biblioteca/templates/formulario_buscar . html 


<html> 

<head> 

<title>Buscar</title> 

</head> 

<body> 

{%  if  errors  %} 

<ul> 

{%  for  error  in  errors  %} 

<li  style="color:  red;">{{  error  }}</li> 
{%  endfor  %} 

</ul> 

{%  endif  %} 

<form  action- '/buscar/"  method="get"> 
<input  type="text"  name="q"> 

<input  type="submit"  value="Buscar"> 

</form> 

</body> 

</html> 


De  esta  forma  podemos  validar  de  forma  simple  las  cadenas  de  consultas: 
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f i localhost:8000/b jscar/?q= Jna+consulta+ de+  mas+ de+20+ caracteres  C / !■  fj  ft  = 


• Por  favor  introduce  un  tenuino  de  busqueda  menor  a 20  caracteres. 
Search 


Figura  7-2.  Ejemplo  de  un  formulario  para  validar  cadenas  de  datos. 

Construir  un  formulario  para  contactos 

A pesar  de  que  buscamos  mejorar  el  formulario  de  busquedas  en  el  ejemplo  pasado, 
varias  veces  y lo  mejoramos  de  forma  elegante,  sigue  siendo  fundamentalmente 
simple;  ya  que  contiene  unicam ente  un  campo  'q'.  Debido  a que  era  tan  simple,  no 
utilizamos  la  libreria  de  formularios  de  Django,  para  tratar  con  ello.  Pero  los 
formularios  mas  complejos,  necesitan  un  tratamiento  mas  complicado  - y ahora 
desarrollaremos  algo  mas  complicado:  un  formulario  para  un  sitio  de  contactos. 

El  formulario  de  contactos  permitira  a los  visitantes  del  sitio  enviar  un  poco  de 
retroalimentacion  junto  con  una  direction  e-mail  opcional.  Despues  de  que  el 
formulario  sea  enviado  y los  datos  validados,  automaticamente  enviara  un  mensaje 
via  e-email  al  personal  del  sitio  Web. 

Empezamos  con  la  plantilla,  formulario-contactos.html. 


contactos/ templates/ formulario-contactos 


<html> 

<head> 

<title>Contactanos</title> 

</head> 

<body> 

<hl>Contactanos</hl> 

{%  if  errors  %} 

<ul> 

{%  for  error  in  errors  %} 

<li>{{  error  }}</li> 

{%  endfor  %} 

</ul> 

{%  endif  %} 

<form  action="/contactos/"  method="post">{%  csrf_token  %} 

<p>Asunto:  <input  type="text"  name="asunto"></p> 

<p>E-mail  (opcional):  <input  type="text"  name="email"></p> 

<p>Mensaje:  <textarea  name="mensaje"  rows="10"  cols="50"x/textarea></p> 
<input  type="submit"  value="Enviar"> 

</form> 

</body> 

</html> 

Definimos  tres  campos  en  la  plantilla:  el  asunto,  la  direction  de  correo  electronico 
y el  mensaje.  El  segundo  es  opcional,  pero  los  otros  dos  campos  son  obligatorios. 
Observa  que  estamos  usando  el  metodo="post"  en  lugar  de  el  metodo="get"  porque 
al  enviar  el  formulario,  este  tiene  efectos  secundarios  -envia  un  e-mail.  Tambien 
observa  que  copiamos  la  forma  de  mostrar  los  errores  de  el  codigo,  de  la  anterior 

plantillaformulario_biiscar.html. 
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Si  continuamos  siguiendo  el  camino,  que  establecimos  al  crear  la  vista  buscarQ  de 
la  seccion  anterior,  escribimos  la  URLconf  y construimos  una  version  preliminar  de  la 
vista  contactosQ  asi: 


misitio/urls .py 


from  contactos. views  import  contactos 

urlpatterns  = [ 

# ... 

url(r'Acontactos/$',  contactos), 

# ... 

] 


contactos/views . py 


from  django. core. mail  import  send_mail 
from  django. http  import  HttpResponseRedirect 
from  django. shortcuts  import  render 

def  contactos(request): 
errors  = [] 

if  request. method  ==  'POST': 

if  not  request. POST. get('asunto',  "): 

errors. append('Por  favor  introduce  el  asunto.  ) 
if  not  request. POST. get('mensaje', "): 

errors. append('Por  favor  introduce  un  mensaje.) 
if  request.POST.get('emair)  and  not  in  request. POST['email']: 
errors. append('Por  favor  introduce  una  direccion  de  e-mail  valida.') 
if  not  errors: 

send_mail(  request. POST['asunto'],  request. POST['mensaje'], 
request. POST. get('emair,  'noreply@example.com'), 
['siteowner@example.com'],  ) 

return  HttpResponseRedirect('/contactos/gracias/') 
return  render(request,  'formulario-contactos.html',  {'errors':  errors}) 

(Si  continuas  siguiendo  los  ejemplos,  tal  vez  te  preguntes,  ^Si  debes  poner  la  vista 
en  el  archivo  biblioteca/views.py.  Aunque  este  no  tenga  nada  que  ver  con  la 
aplicacion  biblioteca,  o debes  de  ponerla  en  otro  lugar?  Esta  decision  es  tuya;  a 
Django  no  le  importa,  con  tal  de  que  la  vista  apunte  a la  URLconf.  Aunque 
personalmente  deberias  crear  un  directorio  separado,  algo  asi  como:  contactos,  en  el 
mismo  nivel  en  el  que  esta  la  aplicacion  biblioteca,  en  el  arbol  de  directorios, 

conteniendo  un  archivo  vacio init .py  y una  vista  views.py. 

Algunas  novedades  que  pasan  aqui: 

■ Estamos  comprobando  que  request.method  sea  'POST'.  Esto  unicamente  sera 
verdadero  en  los  casos  en  que  se  envie  el  formulario  y no  en  el  caso  de  que 
alguien  simplemente  mira  el  formulario  de  contactos  (En  este  ultimo  caso 
request.method  sera  fijado  como  'GET',  porque  los  navegadores  Web 
normalmente  exploran  usando  GET,  no  POST.)  Esto  hace  mas  agradable  aislar 
“El  formulario  para  mostrar”  de  los  casos  en  que  se  necesite  presentar  el 
“Procesamiento  de  formularios”. 

■ En  lugar  de  usar  request.GET,  estamos  usando  request.POST  para  acceder  a 
los  datos  del  formulario  de  envio.  Esto  es  necesario  porque  el  formulario 
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HTML  en  formulario-contactos.html  usa  method="post".  Si  la  vista  es 
accedida  via  POST,  en  lugar  de  request. GET  estara  vacia. 

■ Esta  vez  tenemos  dos  campos  requeridos,  asunto  y mensaje,  asi  que  tenemos 
que  validar  ambos.  Observa  que  utilizamos  request.POST.getO  y proveemos 
una  cadena  en  bianco  como  el  valor  por  omision  para  el  tercer  campo;  esta  es 
una  manera  agradable  y corta  de  manejar  ambos  casos,  para  evitar  que  falten 
claves  y se  pierdan  datos. 

■ Aunque  el  campo  de  email  no  es  requerido,  todavia  podemos  validarlo  si  nos 
lo  envian.  Nuestro  algoritmo  de  validacion  es  fragil  - solo  comprobamos  que 
la  cadena  contenga  un  caracter  @.  En  el  mundo  real,  necesitamos  una 
validacion  mas  robusta  (y  Django  nos  la  proveera,  en  breve  te  mostraremos 
como.) 

■ Estamos  usando  la  funcion  django. core. mail. send_mail  para  enviar  un  e-mail. 
Esta  funcion  tiene  cuatro  argumentos  obligatorios:  el  asunto  y el  cuerpo  del 
mensaje,  la  direction  del  emisor,  y una  lista  de  direcciones  del  destino. 
send_mail  es  un  wrapper  en  torno  a la  clase  EmailMessage  de  Django,  la  cual 
provee  caracteristicas  avanzadas  tales  como  archivos  adjuntos,  mensajes 
multiples  y un  control  completo  sobre  los  encabezados  del  mensaje. 

■ Ten  en  cuenta  que  para  usar  el  envio  de  e-mail  usando  send_mail(),  tu 
servidor  debe  de  estar  configurado  para  enviar  emails,  y Django  debe  de 
informar  al  servidor  sobre  la  salida  de  e-mails.  Mas  adelante  configuraremos 
un  servidor  de  correo  que  te  permitira  enviar  emails  en  el  proceso  de 
desarrollo. 

■ Despues  de  que  el  e-mail  es  enviado  con  “exito”,  redirige  al  usuario  a otra 
pagina  retornando  un  objeto  HttpResponseRedirect.  Te  dejaremos  la 
implementation  de  la  pagina  “enviado  con  exito”  (ya  que  es  una  simple 
vista/URLconf/plantilla)  pero  es  necesario  explicar  que  debes  usar  un 
redirecionamiento  para  dirigir  al  usuario  a otro  lugar,  en  vez  de  por  ejemplo, 
simplemente  llamar  a renderO  con  una  plantilla  alii  mismo. 

Esta  es  la  razon:  Si  un  usuario  selecciona  actualizar  sobre  una  pagina  que 
muestra  una  consulta  POST,  la  consulta  se  repetira.  Esto  probablemente  lleve  a un 
comportamiento  no  deseado,  por  ejemplo,  que  el  registro  se  agregue  dos  veces  a la 
base  de  datos.  Redirigir  luego  del  POST  es  un  patron  util  que  puede  ayudarte  a 
prevenir  este  escenario.  Asi  que  luego  de  que  se  haya  procesado  el  POST  con  exito, 
siempre  redirige  al  usuario  a otra  pagina  en  lugar  de  retornar  el  HTML  directamente. 
Esta  es  una  buena  practica  de  desarrollo  Web 

<■  localtostaOClO/contacW  ^ c]  S’  SS  5\  & 1%  = 

Contactanos 


E-mail  (opcional): 


■Htt 


Figura  7-3.  Ejemplo  de  un  formulario  para  contactos. 
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La  vista  trabaja,  pero  algunas  funciones  de  validation  son  “repetitivas”  Imagina 
procesar  un  formulario  con  una  docena  de  campos,  ^Realmente  quieres  escribir 
todas  esas  declaraciones  if? 

Otro  problema  es  si  el  usuario  ha  cometido  algun  error,  el  formulario  deberia  volvera 
mostrarse,  junto  a los  mensajes  de  error  resaltados.  Los  campos  deberian  rellenarse 
con  los  datos  previamente  suministrados,  para  evitarle  al  usuario  tener  que  volver  a 
tipear  todo  nuevamente.  (El  formulario  deberia  volver  a mostrarse  una  y otra  vez, 
hasta  que  todos  los  campos  se  hayan  rellenado  correctamente.)  Podemos  devolver 
manualmente  los  datos  POST  a la  plantilla,  pero  tendriamos  que  corregir  los  campos 
en  HTML  para  insertar  el  valor  apropiado  en  el  lugar  correcto. 

Finalmente  esta  es  la  vista  y la  plantilla  final: 


contactos/views . py 


def  contactos(request): 
errors  = [] 

if  request. method  ==  'POST': 

if  not  request. POST. get('asunto',  "): 

errors. append('Por  favor  introduce  el  asunto .') 
if  not  request. POST. get('mensaje',  "): 

errors. append('Por  favor  introduce  un  mensaje.') 
if  request.POST.get('emaN)  and  '@'  not  in  request. POST['email']: 
errors. append('Por  favor  introduce  una  direccion  de  e-mail  valida.') 
if  not  errors: 
send_mail( 

request.  POST['asunto'], 
request.  POST['mensaje'], 

request. POST. get('email',  'noreply@example.com'), 
['siteowner@example.com'], ) 

return  HttpResponseRedirect('/contactos/gracias/') 
return  render(request,  'formulario-contactos.html',  {'errors':  errors, 
'asunto':  request.POST.get('asunto', "), 

'mensaje':  request. POST.get('mensaje', "), 

'email':  request. POST.get('email',  "), 

}) 


contactos/ templates/ formulario-contactos . html 


<html> 

<head> 

<title>Contactanos</title> 

</head> 

<body> 

<h  l>Contactanos</h  1> 

{%  if  errors  %} 

<ul> 

{%  for  error  in  errors  %} 

<li>{{  error  }}</li> 

{%  endfor  %} 

</ul> 

{%  endif  %} 

<form  action="/contactos/"  method="post">{%  csrf_token  %} 
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<p>Asunto:  <input  type="text"  name="asunto"  value="{{  asunto  }}"></p> 

<p>E-mail  (opcional):  <input  type="text"  name="email"  value="{{  email  }}"></p> 
<p>Mensaje:  ctextarea  name="mensaje"  rows="10"  cols="50" 
value="{{  mensaje  }}"></textarea></p>  <input  type="submit"  value="Enviar"> 
</form> 

</body> 

</html> 

Como  seguramente  te  habras  dado  cuenta,  el  proceso  de  validation  de  datos,  no 
es  una  tarea  sencilla,  ya  que  introduce  una  buena  cantidad  de  oportunidades  para 
cometer  errores  humanos. 

Esperamos  que  comiences  a ver  la  oportunidad  que  ofrecen  algunas  bibliotecas  de 
alto  nivel  de  Django,  que  manejan  los  trabajos  relacionados  con  la  validation,  por  ti. 


Tu  primer  formulario  usando  clases 

Django  posee  una  libreria  llamada  django. forms,  que  maneja  muchos  tipos  de  temas 
que  hemos  explorado  en  este  capitulo  -Formularios  para  validar  y mostrar  HTML. 
Sumerjamonos  dentro  de  nuestra  aplicacion  para  formularios  de  contactos,  usando 
ahora  los  formularios  del  framework  Django. 


La  libreria  “forms”  de  Django:  A traves  de  la  comunidad  de  Django,  puedes 
haber  leido  o escuchado  alguna  conversation  sobre  algo  llamado  django.newforms. 
Cuando  la  gente  pregunta  sobre  django.newforms,  ellos  se  refieren  ahora  a 
django.forms  - la  libreria  que  cubriremos  en  este  capitulo  -. 

La  razon  del  cambio  de  nombre  es  historica.  Cuando  Django  fue  lanzado  al 
publico  por  primera  vez,  poseia  un  sistema  de  formularios  complicado  y confuso, 
django.forms.  Como  hacia  muy  dificultosa  la  production  de  formularios,  fue  rescrito 
y llevo  por  nombre  django.newforms.  Sin  embargo  algunas  personas  siguieron 
usando  el  viejo  sistema.  Cuando  Django  1.0  fue  lanzado,  el  viejo  django.forms  se  fue 
y django.newforms  se  convirtio  en  django.forms  otra  vez. 


Lo  primero  que  necesitas  para  usar  el  framework  de  formularios  es  definir  una 
clase  Form  para  cada  formulario  HTML  que  quieras  crear,  En  este  caso  unicamente 
queremos  un  formulario,  asi  que  solo  necesitamos  tener  una  clase  Form.  Esta  clase 
puede  localizarse  en  cualquier  lugar  - incluso  podemos  ponerla  directamente  en  el 
archivo  de  vistas  views.py  - pero  entre  la  comunidad  la  convention  es  ponerla  en  un 
archivo  separado  llamado  forms. py.  Crea  este  archivo  en  el  mismo  directorio  que 
views.py  e introduce  lo  siguiente: 


contactos/ forms .py 


from  django  import  forms 

class  FormularioContactos(forms.Form): 

asunto  = forms.  CharFieldQ 

email  = forms. EmailField(required=  ) 

mensaje  = forms. CharField() 

Esto  es  bastante  intuitivo  y muy  similar  a la  sintaxis  de  modelos  de  Django.  Cada 
campo  en  el  formulario  es  representado  por  un  tipo  de  clase  Field  - CharField  y 
EmailField  son  unicamente  los  tipos  de  campos  usados  como  atributos  de  la  clase 
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Form.  Cada  campo  es  requerido  por  defecto,  para  hacer  que  el  campos  email  sea 
opcional,  necesitas  especificar  required=False. 

Saltemos  al  interprete  interactivo  de  Python  y veamos  lo  que  esta  clase  puede 
hacer  (usando  python  manage.py  shell). 

La  primera  cosa  que  puede  hacer  es  mostrarse  a si  misma  como  HTML: 

»>  from  contactos. forms  import  FormularioContactos 
»>  f = FormularioContactos() 

»>  print  (f) 

<tr><th><label  for="id_asunto">Asunto:</labelx/th><td><input  type="text" 
name-'asunto"  id="id_asunto"  /></td></tr> 

<tr><th><label  for="id_email">Email:</labelx/th><tdxinput  type="text" 
name="email"  id="id_email"  /></tdx/tr> 

<tr><th><label  for="id_mensaje">Mensaje:</labelx/th><td><input  type="text" 
name="mensaje"  id- 'id_mensaje"  /></td></tr> 

Para  mayor  accesibilidad,  Django  agrega  una  etiqueta  <label>  a cada  campo,  La 
ideas  es  hacer  el  comportamiento  predeterminado  tan  optimo  como  sea  posible. 

La  salida  predeterminada  se  da  en  forma  de  tabla,  usando  una  <table>  en  formato 
HTML,  pero  existen  algunas  otros  tipos  de  salidas,  por  ejemplo: 

>x#Como  lista  (print  f.as_ul(),  si  usas  Python  2 ) 

»>  print  (f.as_ul()) 

<li><label  for="id_asunto">Subject:</label>  <input  type="text" 
name-'asunto"  id- 'id_asunto"  /></li> 

<li><label  for="id_email">Email:</label>  <input  type="text" 
name="email"  id="id_email"  /x/li> 

<li><label  for="id_mensaje">Message:</label>  <input  type="text" 
name- 'mensaje"  id="id_mensaje"  /></li> 

»>  #Como  Parrafo 
»>  print  (f.as_p()) 

<pxlabel  for="id_asunto">Subject:</label>  <input  type-'text" 
name-'asunto"  id="id_asunto"  /></ p> 

<pxlabel  for="id_email">Email:</label>  <input  type="text" 
name="email"  id="id_email"  /></ p> 

<pxlabel  for="id_mensaje">Mensaje:</label> 

Observa  que  las  etiquetas  <table>,  <ul>  y <form>  no  se  han  incluido;  debes 
definirlas  por  tu  cuenta  en  la  plantilla.  Esto  te  da  control  sobre  el  comportamiento  del 
formulario  al  ser  suministrado.  Los  elementos  label  si  se  incluyen,  y proveen  a los 
formularios  de  accesibilidad  “desde  fabrica”. 

Estos  metodos  son  solo  atajos  para  los  casos  comunes,  en  los  que  es  necesario 
“mostrar  el  formulario  completo’’.  Sin  embargo  tambien  puedes  mostrar  un  campo 
en  particular: 

»>  print  (f['asunto']) 

<input  type="text"  name-'asunto"  id="id_asunto"  /> 

»>  print  (f['mensaje']) 

<input  type="text"  name="mensaje"  id="id_mensaje"  /> 


La  segunda  cuestion  sobre  los  objetos  Form  es  como  hacer  algo  de  validation  de 
datos.  Para  validar  datos,  crea  un  nuevo  objeto  Form  y pasale  un  diccionario  de  datos 
que  vincule  los  nombres  de  los  campos  con  los  datos: 
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»>  f = FormularioContactos({'asunto':  'Hola',  'email':  'adrian@example.com', 

'mensaje':  'jBuen  sitio!'}) 

Una  vez  que  asocias  datos,  con  una  instancia  de  Form,  haz  creado  un  formulario 
“vinculado” 

»>  f.is_bound 

True 

Una  instancia  de  formulario  puede  estar  en  uno  de  dos  estados:  bound 
(vinculado)  o unbound  (no  vinculado).  Una  instancia  bound  se  construye  con  un 
diccionario  (o  un  objeto  que  funcione  como  un  diccionario)  y sabe  como  validar  y 
volver  a representar  sus  datos.  Un  formulario  no  vinculado  (unbound)  no  tiene  datos 
asociados  y simplemente  sabe  como  representarse  a si  mismo. 

Llama  al  metodo  is_valid()  en  un  cualquier  formulario  vinculado  para  saber  si  lo 
datos  son  validos.  En  el  ejemplo  hemos  pasado  un  valor  valido  a cada  campo  de  la 
clase  Form,  asi  que  es  completamente  valido. 

»>  f.is_valid() 

True 

Aun  si  no  pasamos  el  campo  email,  el  formulario  sigue  siendo  valido,  porque 
hemos  especificado  que  el  campo  sea  opcional  con  required=False 

»>  f = FormularioContactos({'asunto':  'Hola',  'mensaje':  'jBuen  sitio!’}) 

»>  f.is_valid() 

True 

Pero  si  dejamos  ya  sea  asunto  o mensaje,  el  Formulario  ya  no  sera  valido: 

»>  f = FormularioContactos({'asunto’:  'Hola'}) 

»>  f.is_valid() 

False 

»>  f = FormularioContactos({'asunto':  'Hola',  'mensaje': "}) 

»>  f.is_valid() 

False 

Tambien  puedes  obtener  un  mensaje  mas  especifico  sobre  los  errores  de  un 
campo  en  particular,  de  esta  forma: 

»>  f = FormularioContactos({'asunto':  'Hola',  'mensaje':  }) 

»>  f['mensaje']. errors 

[u'Este  campo  es  obligatorio.’] 

»>  f['asunto']. errors 

D 

»>  f['email']. errors 

D 

Cada  Formulario  vinculado  que  instanciemos  contiene  un  atributo  con  una  variable 
llamada  errors  en  forma  de  diccionario  que  asocia  los  nombres  de  los  campos  con  la 
lista  de  mensajes  de  errores  a mostrar. 

»>  f = FormularioContactos({'asunto':  'Hola',  'mensaje': "}) 

»>  f.errors 

{'mensaje':  [u'Este  campo  es  obligatorio.']} 


143  CAPITULO  7 FORMULARIOS 


Finalmente,  cuando  instanciemos  un  Formulario  que  contenga  datos  que  han 
sido  encontrados  validos,  tendremos  disponible  un  atributo  llamado  cleaned_data.  El 
cual  es  un  diccionario  de  datos  enviados  “Limpiamente”.  Sin  embargo  el  framework 
de  formularios  hace  mas  que  validar  los  datos,  tambien  los  convierte  a tipos  de  datos 
Python: 

»>  f = FormularioContactos({'asunto':  'Hola',  'emairi'adria^example.com', 

'mensaje':  'Buen  sitio!'}) 

»>  f.is_valid() 

True 

»>  f.cleaned_data 

{'mensaje':  u'Buen  sitio!’,  ’email1:  u’adrian@example.com’,  ’asunto’:  u’Hola’} 

Nuestro  formulario  de  contactos  unicamente  trata  con  cadena,  las  cuales 
convierte  “limpiamente”  en  objetos  Unicode  -pero  si  utilizaramos  IntegerField  o 
DateField,  el  framework  de  formularios  se  aseguraria  de  usar  cleaned_data 
apropiadamente  para  tratar  con  enteros  en  Python  o con  objetos  datetime. date  para 
los  campos  dados. 

Ligando  formularios  a vistas 

Con  un  basico  conocimiento  sobre  la  forma  en  que  trabajan  las  clases  Form,  ahora 
puedes  ver  como  usar  esta  infraestructura  para  remplazar  algo  de  codigo  repetitivo 
en  la  vista  contactos 0 que  creamos  anteriormente.  Esta  es  la  forma  en  que  podemos 
rescribir  la  vista  contactosQ,  para  usar  el  framework  de  formularios  de  Django: 


contactos/views .py 


from  django. shortcuts  import  render 

from  contactos. forms  import  FormularioContactos 

def  contactos(request): 

if  request. method  ==  ’POST’: 

form  = FormularioContactos(request.POST) 
if  form.is_valid(): 

cd  = form.cleaned_data 
send_mail( 
cd[’asunto’], 
cdf’mensaje’], 

cd.get(’emair,  noreply@example.com’), 
[’siteowner@example.com’], 

) 

return  HttpResponseRedirect(’/contactos/gracias/') 

else: 

form  = FormularioContactos() 

return  render(request,  'formulario-contactos.html',  {'form':  form}) 


contactos/ templates/ formulario-contactos . html 


<html> 

<head> 

<title>Contactanos</title> 

</head> 

<body> 

<hl>Contactanos</hl> 
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{%  if  form. errors  %} 

<p  style="color:  red;">Por  favor  corrige  lo  siguiente: 

</p> 

{%  endif  %} 

<form  action-"'  method="post">{%  csrf_token  %} 

<table> 

{{ form.as_table }} 

</table> 

<input  type-'submit"  value="Enviar"> 

</form> 

</body> 

</html> 

Trata  de  ejecutar  esto  localmente.  Carga  el  formulario,  envfalo  sin  datos,  ahora 
introduce  una  direction  de  correo  electronica  no  valida,  y finalmente  envialo  con  los 
datos  correctamente. 

f & localhost:8000/ contactos/  7 C / H i^\  ii  A — 

Contactanos 


Asunto: 

Email: 

Mensaje: 


Figura  7-4.  Ejemplo  de  un  formulario  para  contactos  usando  la  clase  form. 

jObserva  cuanto  codigo  repetitivo  hemos  quitado!  El  framework  de  formularios 
maneja  la  forma  de  mostrar  el  HTML,  la  validacion,  la  limpieza  de  datos  y se  encarga 
de  volver  a mostrar  el  formulario  con  los  errores  resaltados. 

^ & I oca  I h ost: 8000 /contactos/  ^ C / ffi  ^ A = 

Contactanos 


Por  favor  corrige  lo  siguiente: 

• Este  campo  es  obKgatorio. 

Asunto: 

Email:  | saulexample.com 

• Este  campo  es  obKgatorio. 

Mensaje: 


Figura  7-5.  Formulario  para  contactos  usando  la  clase  form  y la  validacion 

automaticas. 


9 

Advertencia:  Aunque  dependiendo  de  la  configuration  de  tu  servidor  de 
email,  puedes  obtener  un  mensaje  de  error  cuando  llames  a send_mail(),  pero 
ese  es  otro  asunto. 
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Enviar  emails  usando  django 

Aunque  Python  hace  relativamente  facil  el  envio  de  email,  usando  el  modulo  smtplib, 
Django  ofrece  un  par  de  contenedores  livianos  sobre  el.  Estos  contenedores  hacen 
que  el  envio  de  emails  sea  extraordinariamente  rapido,  especialmente  en  el 
desarrollo  de  tu  proyecto,  cuando  necesitas  probar  el  envio  correcto  de  emails,  por  lo 
que  Django  provee  soporte  para  plataformas  que  no  pueden  utilizar  SMPT. 

El  codigo  se  localiza  en  el  modulo  django. core. mail. 


CONFIGURAR  UN  SERVIDOR  DE  CORREO  EN  DJANGO 

En  Django  puedes  enviar  un  email  en  dos  lineas,  usando  el  metodo  send_mail(): 
Primero  inicia  el  interprete  interactive  con  el  comando  python  manage.py  shell: 

»>from  django. core. mail  import  send_mail 
>»send_mail('Este  es  el  argumento',  'Aqui  va  el  mensaje.', 
’administrador@example.com',  ['para@example.com'],  fail_silently=False) 

El  correo  se  envia  usando  el  servidor  SMPT,  con  el  puerto  y el  host  especificado  en 
el  archivo  de  configuracion  setting.py,  mediante  EMAIL_HOST  y EMAIL_PORT, 
mientras  que  las  variables  EMAIL_HOST_USER  y EMAIL_HOST_PASSWORD  se  usan 
para  autentificarte  con  el  servidor  SMPT  si  asi  se  requiere,  por  otra  parte 
EMAIL_USE_TLS  y EMAIL_USE_SSL  se  utilizan  para  controlar  las  conexiones  seguras 
y por  ultimo  EMAIL_BACKEND  se  utiliza  para  configurar  el  servidor  de  correo  a 
utilizar. 

Por  omision  Django  utiliza  SMTP,  como  la  configuracion  por  defecto.  Si  quieres 
especificarla  explicitamente  usa  lo  siguiente  en  el  archivo  de  configuraciones: 

EMAIL_BACKEND  = 'django.  core.  mail,  backends.  smtp.EmailBackend' 


Un  servidor  de  correo  usando  la  terminal 

La  manera  mas  facil  de  configurar  el  envio  de  email  de  forma  local  es  utilizando  la 
consola.  De  esta  forma  el  servidor  de  correo  dirige  todo  el  email  a la  salida  estandar, 
permitiendote  revisar  el  contenido  del  correo  en  la  terminal. 

Solo  necesitas  especificar  el  manejador  de  correo,  usando  la  siguiente 
configuracion: 

EMAIL_BACKEND  = 'django.  core.  mail,  backends,  console.  EmailBackend' 

De  esta  forma  los  emails  son  redirigidos  a la  salida  estandar  de  la  terminal,  para 
que  los  puedas  visualizar. 

Un  servidor  de  correo  “bobo” 

Asi  como  se  pueden  recibir  correos  mediante  la  terminal,  es  posible  tambien 
configurar  un  servidor  de  correo  “bobo”,  que  como  su  nombre  sugiere  solo  Simula  el 
envio  de  correos  de  verdad. 

Para  especificarlo,  solo  usa  la  siguiente  configuracion: 

EMAIL_BACKEND  = 'django. core. mail. backends. dummy. EmailBackend' 
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Este  servidor  de  correo,  no  esta  disenado  para  su  uso  en  production  -ya  que  solo 
provee  una  forma  conveniente  de  enviar  emails  que  puede  ser  usado  en  desarrollo  de 
forma  local. 

Otra  forma  de  utilizar  un  servidor  SMPT  “tonto”  que  reciba  los  emails  localmente 
y puedas  visualizarlos  en  la  terminal,  es  usando  una  clase  incorporada  en  Python  que 
inicia  un  servidor  de  correo  con  un  solo  comando: 

python  -m  smtpd  -n  -c  DebuggingServer  localhost:1025 

Este  comando  inicia  el  servidor  de  correo  en  el  puerto  1025,  en  el  ‘host'  localhost. 
Simplemente  imprime  en  la  salida  estandar  las  cabeceras  y el  cuerpo  de  los  emails, 
asi  que  solo  necesitas  configurar  EMAIL_HOST  y EMAIL_PORT  respectivamente  en  el 
archivo  settings.py. 


Cambiando  la  forma  en  que  los  campos  son  renderizados 

Probablemente  la  primer  cosa  que  notaras  cuando  renderices  el  formulario 
localmente  sea  que  el  campo  mensaje  se  visualiza  como  un  <input  type="text">,  y 
quisieras  que  fuera  un  <textarea>.  Podemos  arreglar  esto,  configurando  el  widget  del 
campo. 


contactos/ forms .py 


from  django  import  forms 

class  FormularioContactos  (forms. Form): 
asunto  = forms. CharField() 
email  = forms. EmailField(required=  alsr ) 
mensaje  = forms. CharField(widget=forms.Textarea) 


El  framework  de  formularios  separa  la  logica  de  la  presentacion,  para  cada  campo 
en  un  conjunto  de  widgets.  Cada  tipo  de  campo  tiene  un  widget  por  defecto,  pero 
puedes  sobrescribirlo  facilmente,  o proporcionar  uno  nuevo  de  tu  creation. 


^ & Iocalhosfc8000/contactos/  C ■■  @ 'ft' 

Contaetanos 


Asunto: 

Email: 


Mensaje: 


Figura  7-6.  Formulario  usando  un  widget  textarea. 


Piensa  en  las  clases  Field  como  las  encargadas  de  la  logica  de  validacion,  mientras 
que  los  widgets  se  encargan  de  la  logica  de  presentacion. 
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Configurar  una  longitud  maxima 


Una  de  las  necesidades  mas  comunes  en  cuanto  a validation  es  comprobar  que  un 
campo  tenga  un  cierto  tamano,  es  decir  que  acepte  un  maximo  de  caracteres.  Como 
seguimos  perfeccionando  nuestro  Formulario  de  contactos,  seria  bueno  limitar  el 
asunto  a 100  caracteres.  Todo  lo  que  tenemos  que  hacer  es  agregarle  un  valor 
maximo  a la  opcion  maxjength  de  un  campo  CharField  asi: 


contactos/ forms .py 


from  django  import  forms 

class  FormularioContactos(forms.Form): 

asunto  = forms.  CharField(maxJength=100) 
email  = forms. EmailField(required=  alst ) 
mensaje  = forms.  CharField(widget=forms.Textarea) 

Un  argumento  opcional  minjength  (minimo  requerido),  tambien  esta  disponible. 


Especificar  valores  imciales 

Como  una  mejora  mas  para  nuestro  formulario,  vamos  a agregarle  valores  iniciales  al 
campo  asunto  algo  asi  como;  "jAdoro  este  sitio!"  (Un  poco  de  sugestion  mental,  no  le 
hara  dano  a nadie.)  Para  hacer  esto,  usamos  un  argumento  initial  en  la  definition 
misma  de  la  instancia  del  formulario; 


contactos/views . py 


def  contactos(request): 

if  request. method  ==  'POST': 

form  = FormularioContactos(request.POST) 
if  form.is_valid(): 

cd  = form.cleaned_data 
send_mail( 
cd[' asunto], 
cd['mensaje'], 

cd.get('email',  'noreply@example.com'), 

['siteowner@example.com'], 

) 

return  HttpResponseRedirect('/contactos/gracias/') 

else: 

form  = FormularioContactos(initial={'asunto':  'jAdoro  tu  sitio!'}) 

return  render(request,  'formulario-contactos.html',  {'form':  form}) 

Ahora  el  formulario  initial  mostrara  un  mensaje  en  el  campo  asunto,  cada  vez  que 
el  formulario  sea  cargado. 
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^ & localhost:8000/contactos/  C J*  ■■  ^ igf  "ft 

Contactanos 


Asunto:  jAdoro  tu  sitio! 

Email: 


Mensaje: 


I Subir  [ 


Figura  7-7.  Formulario  mostrando  valores  imciales. 

Observa  que  existe  una  diferencia  entre  pasar  datos  imciales  y pasar  datos 
vinculados  a un  formulario.  La  gran  diferencia  es  que  solo  estamos  pasando  datos 
iniciales,  entonces  el  formulario  no  esta  vinculado,  lo  cual  da  a entender  que  no 
existen  mensajes  de  error. 

Nuestras  propias  reglas  de  validacion 

Imagina  que  hemos  lanzado  al  publico  nuestro  formulario  de  comentarios,  y los 
correos  electronicos  han  empezado  a llegar  a montones,  y nos  encontramos  con  un 
problema:  algunos  mensajes  vienen  con  solo  una  o dos  palabras,  es  poco  probable 
que  tengan  algo  interesante  que  decir.  Por  lo  que  decidimos  adoptar  una  nueva 
politica  de  validacion:  cuatro  palabras  o mas,  por  favor. 

Hay  varias  formas  de  insertar  nuestras  propias  reglas  de  validacion  en  un 
formulario  de  Django.  Si  vamos  a usar  nuestra  regia  una  y otra  vez,  podemos  crear  un 
nuevo  tipo  de  campo.  Sin  embargo,  la  mayoria  de  las  validaciones  que  agreguemos 
seran  de  un  solo  uso,  y pueden  agregarse  directamente  en  el  propio  formulario. 

En  este  caso,  necesitamos  validacion  adicional  sobre  el  campo  mensaje,  asi  que 
debemos  agregar  un  metodo  clean_mensaje()  a nuestro  formulario: 


contactos/ forms .py 


from  django  import  forms 

class  FormularioContactos(forms.Form): 

asunto  = forms.  CharField(max_length=100) 
email  = forms.  EmailField(required=  ) 

mensaje  = forms.  CharField(widget=forms.Textarea) 

def  clean_mensaje(self): 

mensaje  = )lf.cleaned_data['mensaje'] 
num_palabras  = (mensaje. split()) 

if  num_palabras  < 4: 

raise  forms. ValidationError("iSe  requieren  minimo  4 palabras!") 
return  mensaje 

El  sistema  de  formularios  de  Django,  automaticamente  busca  cualquier  metodo 
que  empiece  con  clean_  y termine  con  el  nombre  del  campo.  Si  cualquiera  de  estos 
metodos  existe,  este  sera  llamado  durante  la  validacion. 

Especificamente,  el  metodo  clean_mensaje()  es  llamado  despues  de  la  validacion 
logica  para  el  campo  por  defecto  (en  este  caso,  la  validacion  logica  de  el  campo 
CharField  es  obligatoria).  Dado  que  los  datos  del  campo  ya  han  sido  parcialmente 
procesados,  necesitamos  obtenerlos  desde  el  diccionario  self.cleaned_data  del 
formulario.  Por  lo  que  no  debemos  preocuparnos  por  comprobar  que  el  valor  exista  y 
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que  no  este  vacio;  ya  que  el  valid ador  se  encargara  de  realizar  este  trabajo  por 
defecto. 

Usamos  una  combination  de  len()  y split()  para  contar  la  cantidad  de  palabras.  Si 
el  usuario  ha  ingresado  pocas  palabras  (menos  de  4),  lanzamos  un  error 
forms.ValidationError.  El  texto  que  lleva  esta  exception  se  mostrara  al  usuario  como 
un  elemento  mas  de  la  lista  de  errores. 

Es  importante  que  retornemos  explicitamente  el  valor  limpio  del  campo  al  final  del 
metodo. 

Esto  nos  permite  modificar  el  valor  (o  convertirlo  a otro  tipo  de  Python)  dentro  de 
nuestro  metodo  de  validation.  Si  nos  olvidamos  de  retornarlo,  se  retornara  None  y el 
valor  original  ser  perdera. 

Como  especificar  Etiquetas 

Por  defecto  las  etiquetas  E1TML  autogeneradas  por  los  formularios,  son  creadas  para 
remplazar  los  guiones  bajos  con  espacios  y con  mayusculas  la  primera  letra  de  una 
palabra.  - Asi  por  ejemplo  la  etiqueta  para  el  campo  email  es  "Email"  (^Te  suena 
familiar?  es  el  mismo  algoritmo  que  Django  usa  en  los  modelos,  para  calcular  los 
valores  predeterminados  de  cada  campo  usando  verbose_name,  los  cuales  cubrimos 
en  el  capitulo  5) 

Asi  como  personalizamos  los  modelos  en  Django,  tambien  podemos  personalizar 
las  etiquetas  para  un  campo  determinado.  Usando  para  ello  la  etiqueta  label,  asi: 


contactos/ forms .py 


from  django  import  forms 

class  FormularioContactos(forms.Form): 

asunto  = forms.  CharField(max_length=100) 

email  = forms. EmailField(required=False,  label-Tu  correo  electronico') 

mensaje  = forms.  CharField(widget=forms.Textarea) 

def  clean_mensaje(self): 

mensaje  = self.cleaned_data['mensaje'] 
num_palabras  = (mensaje. split()) 
if  num_palabras  < 4: 

raise  forms. ValidationError("iSe  requieren  minimo  4 palabras!") 
return  mensaje 


^ Iocalhost8000/contactos/  ~ G J*  Tm  "Ht 

Contactanos 

Asunto:  jAdoro  tu  sitio! 

Tu  correo  electronico: 


Mensaje: 


[ Subir  | 


Figura  7-8.  Formulario  mostrando  etiquetas  personalizadas. 
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Diseno  de  formularios  personalizados 

La  plantilla  que  usamos  formulario-contactos.html  usa  el  formato  para  tablas 
{{  form.as_table  }}  para  mostrar  el  formulario,  pero  podemos  visualizar  el  formulario 
de  otras  maneras,  para  tener  un  control  mas  especifico  sobre  la  presentacion. 

La  forma  mas  rapida  de  personalizar  la  presentacion  de  un  formulario  es  usando 
CSS  (hojas  de  estilos).  En  particular,  la  lista  de  errores  puede  dotarse  de  mejoras 
visuales,  y el  elemento 

<ul  class="errorlist">  tiene  asignada  una  clase  para  ese  proposito.  El  CSS  a 
continuation  hace  que  nuestros  errores  salten  a la  vista,  agrega  lo  siguiente  a 
formulario-contactos.html: 

<style  type="text/css"> 

ul.errorlist  { 

margin:  0; 
padding:  0; 

} 

.errorlist  li  { 

background-color:  red; 
color:  white; 
display:  block; 
font-size:  lOpx; 
margin:  0 0 3px; 
padding:  4px  5px; 

} 

</style> 


^ Q localhost:8000/contactos/  ~ C Z'  Tm  $8?  "ft 


Contactanos 

Por  favor  corrige  lo  siguiente: 


Asunto:  jAdoro  tu  sitiol 


Este  cimpo  es  oblig*torio. 


Mensaje: 


| Subir  ~| 


Figura  7-9.  Formulario  mostrando  el  resaltado  de  errores. 

Si  bien  es  conveniente  que  el  HTML  del  formulario  sea  generado  por  nosotros,  en 
muchos  casos  la  disposition  por  defecto  queda  bien  en  nuestra  aplicacion. 

{{  form.as_table  }}  y similares  son  atajos  utiles  que  podemos  usar  mientras 
desarrollamos  nuestra  aplicacion,  pero  todo  lo  que  concierne  a la  forma  en  que 
nuestro  formulario  es  representado  puede  ser  sobrescrito,  casi  siempre  desde  la 
plantilla  misma. 

Cada  widget  de  un  campo  (<input  type="text">,  <select>,  <textarea>,  o similares) 
puede  generarse  individualmente  accediendo  a {{  form.fieldname  }}  en  la  plantilla  y 
cualquier  error  asociado  con  un  campo  esta  disponible  mediante 
{{  form.fieldname.errors  }}.  Con  esto  en  mente,  podemos  construir  nuestras  propias 
plantillas  personalizada  para  nuestro  formulario  de  contactos,  con  el  siguiente 
codigo: 
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contactos/ templates/ formulario-contactos . html 


<html> 

<head> 

<title>Contactanos</title> 

</head> 

<body> 

<hl>Contactanos</hl> 

{%  if  form. errors  %} 

<p  style-'color:  red;"> 

Por  favor  corrige  lo  siguiente: 

</p> 

{%  endif  %} 

<form  action-"'  method="post">{%  csrf_token  %} 
<div  class- 'field"> 

{{ form. asunto. errors  }} 

<label  for="id_asunto">Asunto:</label> 

{{ form. asunto }} 

</div> 


<div  class="field"> 

{{ form. email. errors  }} 

<label  for="id_email">E-mail:</label> 
{{ form. email }} 

</div> 


<div  class="field"> 

{{ form. mensaje. errors  }} 

<label  for="id_mensaje">Mensaje:</label> 
{{ form. mensaje }} 

</div> 


<input  type="submit"  value="Enviar"> 

</form> 

</body> 

</html> 

{{ form. mensaje. errors  }}  muestra  un  <ul  class="errorlist">  si  se  presentan  errores  y 
muestra  una  cadena  de  caracteres  en  bianco  si  el  campo  es  valido  (o  si  el  formulario 
no  esta  vinculado).  Tambien  podemos  tratar  a la  variable  form.mensaje. errors  como 
a un  booleano  o incluso  iterar  sobre  el  mismo  como  una  lista,  por  ejemplo: 

<div  class="field{%  if  form. mensaje. errors  %}  errors{%  endif  %}"> 

{%  if  form. mensaje. errors  %} 

<ul> 

{%  for  error  in  form. mensaje. errors  %} 

<li><strong>{{  error  }}</strongx/li> 

{%  endfor  %} 

</ul> 

{%  endif  %} 

<label  for="id_mensaje">Mensaje:</label> 

{{ form.mensaje }} 

</div> 
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En  caso  de  errores  de  validation,  esto  agrega  a la  clase  “errors”  el  contenedor 
<div>  y muestra  los  errores  en  una  lista  ordenada. 

<?,Que  sigue? 

Este  capitulo  concluye  con  el  material  introductorio  de  este  libro.  - el  tambien 
denominado  “nivel  basico”.  La  siguiente  seccion  del  libro,  en  especial  los  capitulos  8 
al  12  tratan  con  mas  detalle  sobre  el  uso  avanzado  de  Django,  incluyendo  como 
desplegar  una  aplicacion  Django  capitulo  12. 

Luego  de  estos  primeros  siete  capitulos,  deberias  saber  lo  suficiente  como  para 
comenzar  a escribir  tus  propios  proyectos  en  Django.  El  resto  del  material  de  este 
libro  te  ayudara  a completar  las  piezas  faltantes  a medida  que  las  vallas  necesitando. 

Comenzaremos  el  capitulo  8 retrocediendo  un  poco,  volviendo  atras  para  darle 
una  mirada  mas  de  cerca  a las  vistas  y a los  URLconfs  introducidos  por  primera  vez 
en  el  capitulo  3. 


PARTE2 


Nivel  avanzado 


CAPITULO  8 


Vistas  avanzadas  y URLconfs 


^Jn  esquema  limpio  y elegante  en  una  URL,  es  un  detalle  importante  en  una 
aplicacion  Web  de  alta  calidad,  Django  te  permite  disenar  las  URL  que  quieras,  sin 
limitaciones  del  framework,  por  lo  que  no  encontraras  requerimientos  tipo  .php  o 
.cgi.  El  sistema  de  URLconf  que  usa  Django  estimula  a generar  URLs  agradables, 
haciendo  mas  sencillo  el  usarlas,  que  el  no  usarlas1. 

En  el  capitulo  3,  explicamos  las  bases  sobre  el  funcionamiento  de  las  funciones 
vista  de  Django  y las  URLconfs.  En  este  capitulo  conoceremos  en  detalle  algunas 
funcionalidades  mas  avanzadas  en  estas  dos  partes  del  framework. 

Trucos  de  URLconf 

No  hay  nada  de  “especial”  con  las  URLconfs  - como  cualquier  otra  cosa  en  Django, 
son  solo  codigo  Python.  Puedes  aprovecharte  de  esto  de  muchas  maneras,  como  se 
describe  mas  adelante. 

Importacion  de  funciones  de  forma  efectiva 

Considera  esta  URLconf,  que  se  basa  en  el  ejemplo  del  capitulo  3: 
from  django.conf.urls  import  url 

from  misitio. views  import  hola,  fecha_actual,  horas_adelante 

urlpatterns  = [ 

url(r’Ahola/$’,  hola), 
url(r’Afecha/$’,  fecha_actual), 
url(r’Afecha/mas/(\d{l,2})/$’,  horas_adelante), 

] 


Como  se  explico  en  el  capitulo  3,  cada  entrada  en  una  URLconf  debe  incluir  una 
funcion  vista  asociada,  que  se  pasa  directamente  como  un  metodo.  Esto  significa  que 
es  necesario  importar  cada  una  de  las  funciones  de  vista  o views  en  la  parte  superior 
del  modulo. 

Sin  embargo  a medida  que  las  aplicaciones  Django  crecen  en  complejidad,  sus 
URLconf  crecen  tambien,  por  lo  que  mantener  esos  import  puede  ser  tedioso  de 
manejar.  (Por  cada  nueva  funcion  vista,  tienes  que  recordar  importarla  y la 
declaration  de  importaciones  tiende  a volverse  demasiado  larga  si  se  utiliza  este 
metodo).  Es  posible  evitar  esa  tarea  tediosa  importando  el  modulo  views 
directamente. 


1 Para  mas  informacion  sobre  URLs  elegantes,  consulta  el  articulo  titulado  Cool  URIs  don't 
change  (®  http://www.w3.org/Provider/Style/URI)  de  el  creador  de  la  World  Wide  Web;  Tim 
Berners-Lee,  donde  encontraras  excelentes  argumentos  a favor  de  las  URLs  limpias  y usables. 
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Este  ejemplo  de  URLconf  es  equivalente  al  anterior: 

from  django.conf.urls  import  url 

from  misitio  import  views 

urlpatterns  = [ 

url(r’Ahola/$’,  views. hola), 
url(r’Afecha/$’,  views. fecha_actual), 
url(r’Afecha/mas/(d{l,2})/$’,  views. horas_adelante), 

] 


Como  puedes  observar  la  sintaxis  para  la  variable  urlpatterns,  siempre  es  una  lista 
Python  de  una  instancia  de  una  url  () . 

Django  ofrece  otra  forma  de  especificar  la  funcion  vista  para  un  patron  en 
particular  en  la  URLconf:  se  le  puede  pasar  un  string  que  contiene  el  nombre  del 
modulo  y el  nombre  de  la  funcion  en  lugar  del  metodo. 

Continuando  con  el  ejemplo: 

from  django.conf.urls  import  url 

urlpatterns  = [ 

url(r’Ahola/$’,  ’misitio. views. hola’), 
url(r’Afecha/$’,  ’misitio.views.fecha_actual’), 
url(r’Afecha/mas/(d{l,2})/$’,  ’misitio.views.horas_adelante’), 

] 


(Nota  que  los  nombres  de  las  vistas  estan  entre  comillas.  Estamos  usando 
'misitio.views.hola'  - con  comillas,  en  lugar  de  usar  misitio.views.hola  directamente.) 

Al  usar  esta  tecnica  ya  no  es  necesario  importar  las  funciones  vista;  Django  importa 
automaticamente  la  funcion  vista  apropiada,  la  primera  vez  que  sea  necesite,  segun 
la  cadena  que  describa  el  nombre  y la  ruta  de  la  funcion  vista. 

Casos  especiales  de  URLs  en  modo  Debug 

Otra  forma  muy  comun  de  construir  urlpatterns  de  forma  dinamica,  es  simplemente 
comprobando  el  valor  de  la  configuration  DEBUG  en  tiempo  de  ejecucion,  para 
alterar  el  comportamiento  de  las  URLconf  mientras  se  desarrolla  en  el  modo  de 
depuration  de  Django  asi: 

from  django.conf  import  settings 
from  django.conf.urls  import  url 

from  misitio  import  views 

urlpatterns  =[ 

url(r’A$’,  views. indice), 

u rl(r’A(\d{4})/([a-z]{3})/$’ , views. arch ivos_mes) , 

] 

if  settings. DEBUG: 
urlpatterns  +=  [ 

url  (r’Adebuginfo/$’,  views. debug), 

] 
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En  este  ejemplo,  la  URL  /debuginfo/  solo  estara  disponible  si  tu  configuracion 
DEBUG  tiene  el  valor  True. 

Trabajar  en  modo  DEBUG,  significa  sobre  todo  depurar,  por  lo  que  Django,  nos 
provee  de  herramientas  para  manejar  los  casos  mas  comunes  del  desarrollo  Web, 
como  manejar  archivos  estaticos  (hojas  de  estilo,  java  script)  y archivos  media 
(imagenes,  pdf),  de  forma  local.  Django  hace  una  gran  distincion  en  el  manejo  de 
estos  dos  tipos  de  contenido,  mientras  que  se  encarga  de  servir  los  archivos  estaticos 
de  forma  automatica,  para  servir  los  archivos  media  de  forma  local,  es  necesario 
habilitar  una  vista  opcional  y enlazarla  a una  URLconf  en  modo  DEBUG. 

from  django. views. static  import  serve 
from  django. conf  import  settings 
from  django. conf.urls  import  url 

from  misitio  import  views 

urlpatterns  =[ 

url(r’A$’,  views. indice), 

u rl(r’A(\d{4})/([a-z]{3})/$’ , views. arch ivos_mes) , 

] 

if  settings. DEBUG: 
urlpatterns  +=  [ 

url(r’Amedia/(?P<path>.*)$’,  serve, 

{’document_root’:  settings. MEDIA_ROOT, 

}), 

] 


En  este  ejemplo,  llamamos  a la  vista  serve,  que  pertenece  al  paquete  static,  que  se 
encarga  de  servir  directorios,  solo  le  pasamos  la  ruta  especificada  en  MEDIA_ROOT, 
la  cual  contiene  la  raiz  de  los  archivos  media,  esta  vista  se  encargara  de  servir 
archivos  (por  ejemplo  imagenes,  videos)  siempre  y cuando  el  modo  DEBUG  este 
activado.  En  este  ejemplo  la  variable  MEDIA_URL  asume  que  el  valor  es  ‘media’, 
aunque  podemos  cambiarlo  segun  nuestras  necesidades.  De  esta  forma  la  URL 
/media/  solo  estara  disponible  si  la  configuracion  DEBUG  tiene  asignado  el  valor 
True. 


9 

Advertencia:  Esta  vista  es  ineficiente  y no  debe  ser  usada  en  produccion,  por  lo 
que  asegurate  de  usarla  solo  en  el  desarrollo  de  tus  aplicaciones  de  forma  local.  Para 
servir  archivos  en  produccion  utiliza  un  servidor  dedicado,  consulta  el  capitulo  12, 
para  conocer  algunos  servidores  que  te  pueden  ayudar  en  esa  tarea. 


Usar  grupos  con  nombre 

Hasta  ahora  en  todos  nuestros  ejemplos  URLconf  hemos  usado,  grupos  de 
expresiones  regulares  sin  nombre  - es  decir,  ponemos  parentesis  en  las  partes  de  la 
URL  que  queremos  capturar  y Django  le  pasa  ese  texto  capturado  a la  funcion  vista 
como  un  argumento  posicional.  En  un  uso  mas  avanzado,  es  posible  usar  grupos  de 
expresiones  regulares  con  nombre  para  capturar  partes 
de  la  URL  y pasarlos  como  argumentos  clave  a una  vista. 
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ARGUMENTOS  CLAVES  VS.  ARGUMENTOS  POSICIONALES 


A una  funcion  de  Python  se  la  puede  llamar  usando  argumentos  clave  o argumentos 
posicionales  - y,  en  algunos  casos,  los  dos  al  mismo  tiempo.  En  una  llamada  por 
argumentos  clave,  se  especifican  los  nombres  de  los  argumentos  junto  con  los  valores 
que  se  le  pasan.  En  una  llamada  por  argumento  posicional,  sencillamente  pasas  los 
argumentos  sin  especificar  explicitamente  que  argumento  concuerda  con  cual  valor; 
la  asociacion  esta  implicita  en  el  orden  de  los  argumentos. 

Por  ejemplo,  considera  esta  sencilla  funcion: 

def  venta(articulo,  precio,  cantidad): 

print  ("Vendidos:  %s  unidad(es)  de  %s  a %s"  % (cantidad,  articulo,  precio)) 

Para  llamarla  con  argumentos  posicionales,  se  especifican  los  argumentos  en  el 
orden  en  que  estan  listados  en  la  definition  de  la  funcion: 

venta(’Calcetines’,  ’$2.50’,  6) 

Para  llamarla  con  argumentos  de  palabra  clave,  se  especifican  los  nombres  de  los 
argumentos  junto  con  sus  valores.  Las  siguientes  sentencias  son  equivalentes: 

venta(articulo- Calcetines’,  precio- $2.50’,  cantidad=6) 
venta(articulo- Calcetines’,  cantidad=6,  precio- $2.50’) 
venta(precio=’$2.50’,  articulo- Calcetines’,  cantidad=6) 
venta(precio=’$2.50’,  cantidad=6,  articulo- Calcetines’) 
venta(cantidad=6,  articulo- Calcetines’,  precio- $2.50’) 
venta(cantidad=  >,  precio- $2.50’,  articulo- Calcetines’) 

Finalmente,  se  pueden  mezclar  los  argumentos  posicionales  y por  palabra  clave, 
siempre  y cuando  los  argumentos  posicionales  esten  listados  antes  que  los 
argumentos  por  palabra  clave. 

Las  siguientes  sentencias  son  equivalentes  a los  ejemplos  anteriores: 

venta(’Calcetines’,  ’$2.50’,  cantidad=6) 
venta(’Calcetines’,  precio=’$2.50 , cantidad=6) 
venta(’Calcetines’,  cantidad=6,  precio=’$2.50’) 

En  las  expresiones  regulares  de  Python,  la  sintaxis  para  los  grupos  de  expresiones 
regulares  con  nombre  es  (?P<nombre>patron),  donde  nombre  es  el  nombre  del  grupo 
y patron  es  algun  patron  a buscar. 

Aqui  hay  un  ejemplo  de  URLconf  que  usa  grupos  sin  nombre,  en  el  primer  patron 
captura  el  ano,  para  mostrar  una  lista  de  libros  por  ano,  en  el  segundo  captura  el  ano 
y el  mes,  para  mostrar  una  lista  de  libros  de  acuerdo  a un  ano  y mes  en  especifico,  el 
ultimo  muestra  una  lista  de  libros  de  acuerdo  al  ano,  el  mes  y el  dia: 

from  django.conf.urls  import  url 
from  libros  import  views 

urlpatterns  = [ 

url(r'Alibros/(\d{4})/$',  views. libros_ano), 
url(r'Alibros/(\d{4})/(\d{2})/$',  views. libros_mensuales), 
url(r'Alibros/(\d{4})/(\d{2})/(\d{2})/$',  views. libros  diarios), 

] 


Aqui  esta  la  misma  URLconf,  reescrita  para  usar  grupos  con  nombre: 
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from  django.conf.urls  import  url 
from  libros  import  views 

urlpatterns  = [ 

url(r'Alibros/(?P<ano>\d{4})/$',  views. libros_ano), 
url(r'Alibros/(?P<ano>\d{4})/(?P<mes>\w{3})/$',  views. libros_mes), 
url(r'Alibros/(?P<ano>\d{4})/(?P<mes>\w{3})/(?P<dia>\d{2})/$',  views. libros  dia), 

] 


Esto  produce  exactamente  el  mismo  resultado  que  el  ejemplo  anterior,  con  una 
sutil  diferencia:  se  le  pasa  a las  funciones  visto  los  valores  capturados  como 
argumentos  clave  en  lugar  de  argumentos  posicionales. 

Por  ejemplo,  con  los  grupos  sin  nombre  una  peticion  a /libros/2006/03/  resultaria 
en  una  11am ada  de  funcion  equivalente  a esto: 

>»libros_mensuales(request,  ’2006’,  ’03’) 

Sin  embargo,  con  los  grupos  con  nombre,  la  misma  peticion  resultaria  en  esta 
llamada  de  funcion: 

>»libros_mensuales(request,  ano-2006',  mes-03') 


9 

Advertencia:  [Ten  cuidado  con  las  “n”!,  se  incluyen  solo  por  legibilidad,  no 
funcionan  con  Python  2. 


En  la  practica,  usar  grupos  con  nombres  hace  que  tus  URLconfs  sean  un  poco  mas 
explicitas  y menos  propensas  a errores  causados  por  argumentos  - y puedes 
reordenar  los  argumentos  en  las  definiciones  de  tus  funciones  vista.  Siguiendo  con  el 
ejemplo  anterior,  si  quisieramos  cambiar  las  URLs  para  incluir  el  mes  antes  del  ano,  y 
estuvieramos  usando  grupos  sin  nombre,  tendriamos  que  acordarnos  de  cambiar  el 
orden  de  los  argumentos  en  la  vista  libros_mes.  Si  estuvieramos  usando  grupos  con 
nombre,  cambiar  el  orden  de  los  parametros  capturados  en  la  URL  no  tendria  ningun 
efecto  sobre  la  vista. 

Por  supuesto,  los  beneficios  de  los  grupos  con  nombre  tienen  el  costo  de  la  falta  de 
brevedad;  algunos  desarrolladores  opinan  que  la  sintaxis  de  los  grupos  con  nombre 
es  fea  y larga.  Aun  asi,  otra  ventaja  de  los  grupos  con  nombres  es  la  facilidad  de 
lectura,  especialmente  para  las  personas  que  no  estan  mtimamente  relacionadas  con 
las  expresiones  regulares  o con  tu  aplicacion  Django  en  particular.  Es  mas  facil  ver  lo 
que  esta  pasando,  a primera  vista,  en  una  URLconf  que  usa  grupos  con  nombre. 

Una  advertencia  al  usar  grupos  con  nombre  en  una  URLconf  es  que  un  simple 
patron  URLconf  no  puede  contener  grupos  con  nombre  y sin  nombre.  Si  haces  eso, 
Django  no  generara  ningun  mensaje  de  error,  pero  probablemente  descubras  que  tus 
URLs  no  se  estan  disparando  de  la  forma  esperada. 

El  algoritmo  de  combinacion/agrupacion 

Aqui  esta  especificamente  el  algoritmo  que  sigue  el  parser  URLconf,  con  respecto  a 
grupos  con  nombre  vs.  grupos  sin  nombre  en  una  expresion  regular: 

■ Si  existe  algun  argumento  con  nombre,  usara  esos,  ignorando  los  argumentos 
sin  nombre. 
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■ Ademas,  pasara  todos  los  argumentos  sin  nombre  como  argumentos 
posicionales. 

■ En  ambos  casos,  pasara  cualquier  option  extra  como  argumentos  de  palabra 
clave.  Ver  la  proxima  section  para  mas  information. 


Pasarle  opciones  extra  a las  funciones  vista 

A veces  te  encontraras  escribiendo  funciones  vista  que  son  bastante  similares,  con 
tan  solo  algunas  pequenas  diferencias.  Por  ejemplo,  digamos  que  tienes  dos  vistas 
cuyo  contenido  es  identico  excepto  por  la  plantilla  que  utilizan: 


urls .py 


from  django.conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

url(r’Ainicio/$’,  views. vistajnicio), 
url(r’Aindice/$’,  views. vistajndice), 

] 


views . py 


from  django. shortcuts  import  render 
from  biblioteca. models  import  Libro 

def  vistajnicio(request): 
libros  = Libro.  objects.  all() 

return  render(request,  'bienvenidos.html',  {'libros':  libros}) 

def  vista_indice(request,  url): 
libros  = Libro. objects. all() 

return  render(request,  'indice.html',  {'libros':  libros}) 

Con  este  codigo  nos  estamos  repitiendo  y eso  no  es  elegante.  A1  comienzo,  podrias 
pensar  en  reducir  la  redundancia  usando  la  misma  vista  para  ambas  URLs,  poniendo 
parentesis  alrededor  de  la  URL  para  capturarla  y comprobar  la  URL  dentro  de  la  vista 
para  determinar  la  plantilla,  como  mostramos  a continuation: 


urls .py 


from  django.conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

url(r’Ainicio/$’,  views. vistajndice), 
url(r’Aindice/$’,  views. vistajndice), 

] 


views . py 


from  django. shortcuts  import  render 
from  biblioteca.models  import  Libro 

def  vistajndice(request,  url): 
libros  = Libro. objects. all() 
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if  url  ==  ’inicio’: 

plantilla  = ’bienvenidos.html’ 

elif  url  ==  ’indice’: 

plantilla  = ’indice.html’ 

return  render(request,  plantilla,  {’libros’:  libros}) 

Sin  embargo,  el  problema  con  esa  solucion  es  que  acopla  fuertemente  tus  URLs  y 
tu  codigo  Si  decides  renombrar  /inicio/  a /bienvenidos/,  tienes  que  recordar  cambiar 
el  codigo  de  la  vista. 

La  solucion  elegante  involucra  un  parametro  URLconf  opcional.  Cada  patron  en 
una  URLconf  puede  incluir  un  tercer  item:  un  diccionario  de  argumentos  de  palabra 
clave  para  pasarle  a la  funcion  vista. 

Con  esto  en  mente  podemos  reescribir  nuestro  ejemplo  anterior  asi: 


urls .py 


from  django.conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

url(r’Ainicio/$’,  views.vistajndice,  {’plantilla’:  ’bienvenidos.html’}), 
url(r’Aindice/$’,  views.vistajndice,  {’plantilla’:  ’indice.html’}), 

] 


views . py 


from  django. shortcuts  import  render 
from  biblioteca.models  import  Libro 

def  vistajndice(request,  plantilla): 
libros  = Libro.  objects.  all() 
return  render(request,  plantilla,  {’libros’:  libros}) 

Como  puedes  ver,  la  URLconf  en  este  ejemplo  especifica  la  plantilla  en  la  URLconf. 
La  funcion  vista  la  trata  como  a cualquier  otro  parametro. 

Esta  tecnica  de  la  opcion  extra  en  la  URLconf  es  una  genial  forma  de  enviar 
information  adicional  a tus  funciones  vista  sin  tanta  complication.  Por  ese  motivo  es 
que  es  usada  por  algunas  aplicaciones  incluidas  en  Django,  mas  notablemente  por  el 
sistema  de  vistas  genericas,  que  trataremos  en  el  capitulo  11. 

La  siguiente  section  contiene  algunas  ideas  sobre  como  puedes  usar  la  tecnica  de 
la  opcion  extra  en  la  URLconf  como  parte  de  tus  proyectos. 

Simulando  valores  capturados  en  URLconf 

Supongamos  que  posees  un  conjunto  de  vistas  que  son  disparadas  via  un  patron  y 
otra  URL  que  no  lo  es  pero  cuya  logica  de  vista  es  la  misma.  En  este  caso  puedes 
“simular”  la  captura  de  valores  de  la  URL  usando  opciones  extra  de  URLconf  para 
manejar  esa  URL  extra  con  una  unica  vista. 

Por  ejemplo,  podrias  tener  una  aplicacion  que  muestra  algunos  datos  para  un  dia 
en  particular,  con  URLs  tales  como: 

/libros/enero/01/ 

/libros/enero/02/ 

/libros/enero/03/ 

# ... 

/libros/abril/30/ 

/libros/abril/3 1/ 
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A primera  vista  parece  algo  complicado,  sin  embargo  esto  es  simple  de  manejar  - 
puedes  capturar  los  parametros  en  una  URLconf  como  esta  (usando  sintaxis  de 
grupos  con  nombre): 

urlpatterns  = [ 

url(r’Alibros/(?P<mes>\w{3})/(?P<dia>\d{2})/$’,  views. libros  diarios), 

] 


Y la  declaration  de  la  funcion  vista  se  veria  asi: 

def  libros_dia(request,  mes,  dia): 

# .... 

Este  enfoque  es  simple  y directo  - no  hay  nada  que  no  hayamos  visto  antes.  El 
truco  entra  en  juego  cuando  quieres  agregar  otra  URL  que  usa  libros_diarios  pero 
cuya  URL  no  incluye  un  mes  ni / o un  dia. 

Por  ejemplo,  podrias  querer  agregar  otra  URL,  /libros/favoritos/,  que  seria  el 
equivalente  a /libros/enero/06/.  Puedes  sacar  provecho  de  las  opciones  extra  de  las 
URLconf  de  la  siguiente  forma: 

urlpatterns  = [ 

url(r’Alibros/favoritos/$’,  views. libros  dia,  {’mes’:  ’enero’,  ’dia’:  ’06’}), 
url(r’Alibros/(?P<mes>\w{3})/(?P<dia>\d){2}/$’,  views. libros  dia), 

] 


El  detalle  genial  aqui  es  que  no  necesitas  cambiar  tu  funcion  vista  para  nada.  A la 
funcion  vista  solo  le  incumbe  el  obtener  los  parametros  mes  y dia  - no  importa  si  los 
mismos  provienen  de  la  captura  de  la  URL  o de  parametros  extra. 

Convirtiendo  una  vista  en  generica 

Lactorizar,  es  una  buena  practica  de  programacion,  ya  que  nos  permite  aislar  las 
partes  comunes  del  codigo.  Tomemos  por  ejemplo  estas  dos  funciones  Python: 

def  di_hola(nombre_persona): 

print  (’Hola,  %s’  % nombre_persona) 

def  di_adios(nombre_persona): 

print  (’Adios,  %s’  % nombre_persona) 

Podemos  extraer  el  saludo  para  convertirlo  en  un  parametro  asi: 

def  saludar(nombre_persona,  saludo): 

print  (’%s,  %s’  % (saludo,  nombre_persona)) 

Puedes  aplicar  la  misma  filosofia  a tus  vistas  Django,  usando  los  parametros  extra 
de  URLconf. 

Con  esto  en  mente,  puedes  comenzar  a hacer  abstracciones  de  alto  nivel  en  tus 
vistas.  En  lugar  de  pensar  “Esta  vista  muestra  una  lista  de  objetos  Libro”  y “Esta  otra 
vista  muestra  una  lista  de  objetos  Editor”,  descubre  que  ambas  son  casos  especificos 
de  “Una  vista  que  muestra  una  lista  de  objetos,  donde  el  tipo  de  objeto  es  variable”. 
Usemos  este  codigo  como  ejemplo: 


161  CAPITULO  8 BVISTAS  AVANZADAS  Y URLCONFS 


urls .py 


from  django.conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

url(r'Ainicio/$',  views. listajibros) 
url(r'Aindice/$',  views. lista_editores), 

] 


views . py 


from  django. shortcuts  import  render 
from  biblioteca.models  import  Libro,  Editor 

def  listajibros(request): 

listajibros  = Libro.  objects.  all() 

return  render(request,  ’biblioteca/listajibros.htmr,  {’listajibros’:  lista_objetos}) 

def  lista_editores(request): 

lista_editores  = Editor,  objects.  all() 

return  render(request,  ’biblioteca/lista  editores.html’,  {’lista  editores’:  lista_objectos}) 

Ambas  vistas  hacen  esencialmente  lo  mismo:  muestran  una  lista  de  objetos. 
Refactoricemos  el  codigo  para  extraer  el  tipo  de  objetos  en  comun  que  muestran: 


urls .py 


from  django.conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

url(r’AlistaJibros/$’,  views. lista_objetos,  {’model’:  models. Libro}), 
url(r’Alista_editores/$  , views. lista_objetos,  {’model’:  models. Editor}), 

] 


views . py 


from  django. shortcuts  import  render 

def  lista_objectos(request,  model): 
lista_objectos  = model. objects. all() 

plantilla  = ’biblioteca/%sJista.html’  % model. name ,lower() 

return  render(request,  plantilla,  {’lista_objectos’:  lista_objectos}) 

Con  esos  pequenos  cambios  tenemos  de  repente,  una  vista  reusable  e 
independiente  del  modelo.  De  ahora  en  adelante,  cada  vez  que  necesitemos  una  lista 
que  muestre  un  listado  de  objetos,  podemos  simplemente  rehusar  esta  vista 
lista_objectos  en  lugar  de  escribir  mas  codigo. 

A continuation,  un  par  de  notas  acerca  de  lo  que  hicimos: 

■ Estamos  pasando  las  clases  de  modelos  directamente,  como  el  parametro 
model.  El  diccionario  de  opciones  extra  de  URLconf  puede  pasar  cualquier 
tipo  de  objetos  Python  - no  solo  cadenas. 

■ La  linea  model.objects.all()  es  un  ejemplo  de  tipado  de  pato  ( duck  typing) : “Si 
camina  como  un  pato,  y habla  como  un  pato,  podemos  tratarlo  como  un 
pato.”  Nota  que  el  codigo  no  conoce  de  que  tipo  de  objeto  se  trata  model;  el 
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unico  requerimiento  es  que  model  tenga  un  atributo  objects,  el  cual  a su  vez 
tiene  un  metodo  all(). 

■ Estamos  usando  model. name ,lower()  para  determinar  el  nombre  de  la 

plantilla.  Cada  clase  Python  tiene  un  atributo  name que  retorna  el 

nombre  de  la  clase.  Esta  caracteristica  es  util  en  momentos  como  este,  cuando 
no  conocemos  el  tipo  de  clase  hasta  el  momento  de  la  ejecucion.  Por  ejemplo, 
el name de  la  clase  BlogEntry  es  la  cadena  BlogEntry. 

■ En  una  sutil  diferencia  entre  este  ejemplo  y el  ejemplo  previo,  estamos 
pasando  a la  plantilla  el  nombre  de  variable  generico  lista_objectos.  Podemos 
facilmente  cambiar  este  nombre  de  variable  a lislajibros  o lista_editores, 
pero  hemos  dejado  eso  como  un  ejercicio  para  el  lector. 

Debido  a que  los  sitios  Web  impulsados  por  bases  de  datos  tienen  varios  patrones 
comunes,  Django  incluye  un  conjunto  de  “vistas  genericas”  que  usan  justamente  esta 
tecnica  para  ahorrarte  tiempo.  Nos  ocuparemos  de  las  vistas  genericas  incluidas  en 
Django  en  capitulos  siguientes. 

Pasando  opciones  de  configuracion  a una  vista 

Si  estas  distribuyendo  una  aplicacion  Django,  es  probable  que  tus  usuarios  deseen  un 
cierto  grado  de  configuracion.  En  este  caso,  es  una  buena  idea  agregar  puntos  de 
extension  a tus  vistas  para  las  opciones  de  configuracion  que  piensas  que  la  gente 
pudiera  desear  cambiar.  Puedes  usar  los  parametros  extra  de  URLconf  para  este  fin. 

Una  parte  de  una  aplicacion  que  normalmente  se  hace  configurable  es  el  nombre 
de  la  plantilla: 

def  una_vista(request,  plantilla): 

var  = haz_algo() 

return  render_to_response(plantilla,  {’var’:  var}) 


Entendiendo  la  precedencia  entre  valores  capturados  vs.  opciones  extra 

Cuando  se  presenta  un  conflicto,  los  parametros  extra  de  la  URLconf  tienen 
precedencia  sobre  los  parametros  capturados.  En  otras  palabras,  si  tu  URLconf 
captura  una  variable  de  grupo  con  nombre  y un  parametro  extra  de  URLconf  incluye 
una  variable  con  el  mismo  nombre,  se  usara  el  parametro  extra  de  la  URLconf. 

Por  ejemplo,  analicemos  esta  URLconf: 

from  django.conf.urls  import  url 

urlpatterns  = [ 

url(r'Alibros/(?P<id>\d+)/$',  views. listajibros,  {'id':  3}), 

] 


Aqui,  tanto  la  expresion  regular  como  el  diccionario  extra  incluye  un  id.  Tiene 
precedencia  el  id  fijo  especificado  en  la  URL.  Esto  significa  que  cualquier  petition 
(por  ej.  /libros/2/  o /libros/432432/)  seran  tratados  como  si  id  estuviera  fijado  a 3, 
independientemente  del  valor  capturado  en  la  URL. 

Los  lectores  atentos  notaran  que  en  este  caso  es  una  perdida  de  tiempo  y de  tipeo 
capturar  id  en  la  expresion  regular,  porque  su  valor  sera  siempre  descartado  en  favor 
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del  valor  proveniente  del  diccionario.  Esto  es  correcto;  lo  traemos  a colacion  solo 
para  ayudarte  a evitar  el  cometer  este  error. 

Usando  argumentos  de  vista  por  omision 

Otro  truco  comun  es  el  de  especificar  parametros  por  omision  para  los  argumentos 
de  una  vista.  Esto  le  indica  a la  vista  que  valor  usar  para  un  parametro  por  omision  si 
es  que  no  se  especifica  ninguno. 

Veamos  un  ejemplo: 


urls .py 


from  django.conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

(r’Alibros/$’,  views. pagina), 
(r’Alibros/pagina(?P<num>\d+)/$’,  views. pagina), 

] 


views . py 


def  pagina(request,  num=T): 
# La  salida 


Aqui,  ambos  patrones  de  URL  apuntan  a la  misma  vista  - views.pagina  pero  el 
primer  patron  no  captura  nada  de  la  URL.  Si  el  primer  patron  es  disparado,  la  funcion 
paginal)  usara  su  argumento  por  omision  para  num,  "1".  Si  el  segundo  patron  es 
disparado,  paginal)  usara  el  valor  de  num  que  se  haya  capturado  mediante  la 
expresion  regular. 

Es  comun  usar  esta  tecnica  en  combination  con  opciones  de  configuracion,  como 
explicamos  previamente.  Este  ejemplo  implementa  una  pequena  mejora  al  ejemplo 
de  la  section  “Pasando  opciones  de  configuracion  a una  vista”:  provee  un  valor  por 
omision  para  la  plantilla: 

def  una_vista(request,  plantilla- biblioteca/mi_vista.htmr): 
var  = haz_algo() 

return  render_to_response(plantilla,  {’var’:  var}) 

Manejando  vistas  en  forma  especial 

En  algunas  ocasiones  tendras  un  patron  en  tu  URLconf  que  maneja  un  gran  numero 
de  URLs,  pero  necesitaras  realizar  un  manejo  especial  en  una  de  ellas.  En  este  caso, 
saca  provecho  de  la  forma  lineal  en  la  que  son  procesadas  la  URLconfs  y coloca  el 
caso  especial  primero. 

Por  ejemplo,  las  paginas  “agregar  un  objeto”  en  el  sitio  de  administration  de 
Django  estan  representadas  por  la  siguiente  linea  de  URLconf: 

urlpatterns  = [ 

# ... 

url(  A([A/]+)/([A/]+)/add/$’,  views. add_stage), 

# ... 


] 
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Esto  se  disparara  con  URLs  como  /libros/entradas/add/  y /auth/groups/add/.  Sin 
embargo,  la  pagina  “agregar”  de  un  objeto  usuario  (/auth/user/add/)  es  un  caso 
especial  - la  misma  no  muestra  todos  los  campos  del  formulario,  muestra  dos 
campos  de  contrasena,  etc.  Podriamos  resolver  este  problema  tratando  esto  como  un 
caso  especial  en  la  vista,  de  esta  manera: 

def  agregar_estado (request,  appjabel,  model_name): 
if  appjabel  ==  'auth'  and  model_name  ==  'user': 

# do  special-case  code 
else: 

# do  normal  code 

Pero  eso  es  poco  elegante  por  una  razon  que  hemos  mencionado  en  multiples 
oportunidades  en  este  capitulo:  Incrusta  la  logica  de  las  URLs  en  la  vista.  Una  manera 
mas  elegante  seria  la  de  hacer  uso  del  hecho  que  las  URLconfs  se  procesan  desde 
arriba  hacia  abajo  (en  orden  descendente): 

urlpatterns  = [ 

# ... 

url('Aauth/user/add/$’,  views. user_add_stage), 
url('A([A/]+)/([A/]+)/add/$’,  views. add_stage), 

# ... 

] 


Con  esto,  una  peticion  a /auth/user/add/  sera  manejada  por  la  vista 
user_add_stage.  Aunque  dicha  URL  coincide  con  el  segundo  patron,  coincide 
primero  con  el  patron  ubicado  mas  arriba.  (Esto  es  logica  de  corto  circuito). 

Capturando  texto  en  URLs 

Cada  argumento  capturado  es  enviado  a la  vista  como  una  cadena  Python,  sin 
importar  que  tipo  de  coincidencia  se  haya  producido  con  la  expresion  regular.  Por 
ejemplo  en  esta  linea  de  URLconf: 

url(r'Alibros/(?P<ano>\d{4})/$',  views.  libros_por_ano), 

El  argumento  ano  de  views.libros_por_ano()  sera  una  cadena,  no  un  entero,  aun 
cuando  \d{4}  solo  coincidira  con  cadenas  que  representen  enteros. 

Es  importante  tener  esto  presente  cuando  estas  escribiendo  codigo  de  vistas. 
Muchas  funciones  incluidas  con  Python  son  exigentes  (y  eso  es  bueno)  acerca  de 
aceptar  objetos  de  cierto  tipo.  Un  error  comun  es  intentar  crear  un  objeto 
datetime. date  con  valores  de  cadena  en  lugar  de  valores  enteros: 

>»  import  datetime 
»>  datetime. date(’1993’,  T,  '9') 

Traceback  (most  recent  call  last): 

TypeError:  an  integer  is  required 
»>  datetime. date(1993,  7,  9) 

datetime. date(1993,  7,  9) 

Traducido  a una  URLconf  y a una  vista,  este  error  se  veria  asi: 

from  django.conf.urls  import  url 
from  biblioteca  import  views 
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urlpatterns  = [ 

u r I (r' Al i b ros/(\d{4})/(\d{2})/(\d{2})/$' , views . I i bros_d ia) , 

] 

import  datetime 

def  librosdiarios(request,  ano,  mes,  dia): 

# Lo  siguiente  lanza  un  error  del  "TypeError" 

fecha  = datetime. date(anor,  mes,  dia) 

En  cambio  librosdiarios  puede  ser  escrito  correctamente  de  la  siguiente  forma: 


librosdiarios . py 


def  librosdiarios  (request,  ano,  mes,  dia): 
fecha  = datetime. date (int (ano),  int(mes),  int(dia)) 

Observa  que  int()  lanza  un  ValueError  cuando  le  pasas  una  cadena  que  no  esta 
compuesta  unicamente  de  digitos,  pero  estamos  evitando  ese  error  en  este  caso 
porque  la  expresion  regular  en  nuestra  URLconf  ya  se  ha  asegurado  que  solo  se  pasen 
a la  funcion  vista  cadenas  que  contengan  digitos. 

Entendiendo  donde  busca  una  URLconf 

Cuando  llega  una  peticion,  Django  intenta  comparar  los  patrones  de  la  URLconf  con 
la  URL  solicitada  como  una  cadena  Python  normal  (no  como  una  cadena  Unicode). 
Esto  no  incluye  los  parametros  de  GET  o POST  o el  nombre  del  dominio.  Tampoco 
incluye  la  barra  inicial  porque  toda  URL  tiene  una  barra  inicial. 

Por  ejemplo,  en  una  peticion  del  tipo  http://www.example.com/entrada/  Django 
tratara  de  encontrar  una  coincidencia  para  entrada/.  En  una  peticion  para 
http.//www.example.com/entrada/?pagina3  Django  tratara  de  buscar  una 
coincidencia  para  entrada/. 

El  metodo  de  la  peticion  (por  ejemplo  POST,  GET,  HEAD)  no  se  tiene  en  cuenta 
cuando  se  recorre  la  URLconf.  En  otras  palabras,  todos  los  metodos  seran 
encaminados  hacia  la  misma  funcion  para  la  misma  URL.  Es  responsabilidad  de  una 
funcion  vista  manejar  de  forma  distinta  en  base  al  metodo  de  la  peticion. 

Abstracciones  de  alto  nivel  en  las  funciones  vista 

Como  se  menciona  anteriormente,  es  responsabilidad  de  una  vista  manejar  de  forma 
distinta  cualquier  peticion,  por  lo  que  es  necesario  tratar  de  forma  distinta  los 
metodos  POST,  GET. 

Veamos  como  construir  una  vista  que  trate  esto  de  forma  agradable.  Considera 
este  diseno: 


urls. 


from  django.conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

# ... 

url(r’Aindice/$’,  views. indice), 

# ... 


] 
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views. py 


from  django.http  import  Http404,  HttpResponseRedirect 
from  django. shortcuts  import  render 

def  indice(request): 

if  request. method  ==  ’POST’: 
haz_algo_para_post() 
return  HttpResponseRedirect(’/inicio/’) 
elif  request. method  ==  ’GET’: 
haz_algo_para_get() 
return  render(request,  ’pagina.html) 
else: 

raise  Http404() 

En  este  ejemplo,  la  vista  indiceO  se  encarga  de  manejar  tanto  peticiones  POST 
como  GET,  que  son  totalmente  distintas.  La  unica  cosa  que  comparten  en  comun  es 
la  misma  URL:  /inicio/.  Como  tal  es  poco  elegante  manejar  ambas  peticiones  POST  y 
GET  en  la  misma  funcion  de  vista.  Seria  mas  agradable  tener  dos  funciones  de  vista 
separadas  - una  que  maneje  las  peticiones  GET  y la  otra  que  se  encargue  de  las 
peticiones  POST  - por  lo  que  solo  debes  asegurarte  de  llamar  apropiadamente  a la 
que  necesites. 

Podemos  hacer  esto  escribiendo  una  funcion  de  vista  que  delegue  la 
responsabilidad  a otra  vista,  antes  o despues  de  ejecutar  la  logica  definida.  Este 
ejemplo  muestra  como  esta  tecnica  nos  puede  ayudar  a simplificar  la  vista  indice (): 


views. py 


from  django.http  import  Http404,  HttpResponseRedirect 
from  django. shortcuts  import  render 

def  vista_divida(request,  GET=None,  POST=None): 
if  request. method  ==  ’GET’  and  GET  is  not  \lone: 
return  GET(request) 

elif  request. method  ==  ’POST’  and  POST  is  not  \lone: 
return  POST(request) 
raise  Http404 

def  peticion_get(request): 

assert  request.method  ==  ’GET’ 
haz_algo_para_get() 
return  render(request,  ’pagina.html’) 

def  peticion_post(request): 

assert  request.method  ==  ’POST’ 
haz_algo_para_post() 
return  HttpResponseRedirect('/indice/’) 


urls.py 


from  django. conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

(r’Aindice/$\  views. vista_divida,  {’GET’:  views. peticion_get,  ’POST’: 
views.  peticion_post}), 

# ... 

] 
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Veamos  lo  que  hicimos: 

■ Escribimos  una  nueva  vista,  llamada  vista_divida(),  que  delega  la 
responsabilidad  a dos  vistas  mas  basadas  en  el  tipo  de  peticion  mediante  el 
metodo  request.method.  Este  busca  dos  argumentos  clave,  GET  y POST,  los 
cuales  deben  ser  funciones  vista.  Si  request.method  es  'GET',  entonces  se 
llama  a la  vista  GET.  Si  request.method  es  'POST',  entonces  llama  a la  vista 
POST.  Si  request.method  es  algo  como  (E1EAD,  etc.),  o si  GET  o POST  no  son 
proporcionados  a la  funcion,  entonces  se  lanza  un  error  del  tipo  Elttp404 
(pagina  no  encontrada). 

■ En  la  URLconf,  conectamos  /indice/  con  vista_dMda()  y pasamos  los 
argumentos  extras  - la  funcion  de  vista  para  usar  GET  y POST, 
respectivamente. 

■ Finalmente,  separamos  la  vista  vista_divida()  en  dos  funciones  - 
peticion_get()  y peticion_post().  Esto  es  mucho  mas  agradable  que 
empaquetar  toda  la  logica  en  una  simple  vista. 

Observa  que  esta  funcion  de  vista,  tecnicamente  ya  no  tiene  que  comprobar 
request.method,  porque  la  vista_divida()  lo  hace.  (En  el  momento  en  que  se  llame  a 
peticion_post(),  por  ejemplo,  podemos  confiar  que  request.method  es  'post'  ).  No 
obstante,  para  estar  seguros  y para  que  sirva  como  comprobacion,  agregamos  un 
assert  solo  para  asegurarnos  que  request.method  haga  lo  esperado. 

Hemos  creado  una  vista  generica  agradable  que  encapsula  la  logica  y delega  el 
metodo  de  peticion  o request.method  a la  vista.  Nada  en  este  metodo:  vista_divida() 
ata  a nuestra  aplicacion  en  particular,  por  lo  que  que  podemos  rehusarla  en  otros 
proyectos. 

Podemos  encontrar  una  forma  de  perfeccionar  la  vista_divida().  Rescribiendo  el 
metodo,  ya  que  este  asume  que  las  vistas  GET  y POST  no  toman  mas  argumentos  que 
un  request.  Entonces  ^Que  pasa  si  quisieramos  usar  vista_divida()  con  otra  vista,  por 
ejemplo  para  capturar  el  texto  de  una  URLs,  o para  que  tome  argumentos  clave 
opcionales? 

Para  hacer  eso  podemos  usar  una  caracterfstica  genial  de  Python:  que  nos  permite 
usar  argumentos  variables,  definidos  con  asteriscos.  Dejaremos  primero  que  el 
ejemplo  lo  explique: 

def  vista_divida(request,  *args,  **kwargs): 
vista_get  = kwargs.pop(’GET’,  \lone) 
vista_post  = kwargs.pop(’POST\  None) 
if  request.method  ==  'GET'  and  vista_get  is  not  Jone: 
return  vista_get(request,  *args,  **kwargs) 
elif  request.method  ==  ’POST’  and  vista_post  is  not  None: 
return  vista_post(request,  *args,  **kwargs) 
raise  Http404 

Refactorizemos  el  metodo  vista_divida  para  remover  los  argumentos  clave  GET  y 
POST,  y para  poder  usar  *args  y **kwargs  (Observa  los  asteriscos).  Esta  es  una 
caracterfstica  de  Python  que  permite  a las  funciones  aceptar  de  forma  dinamica  y 
arbitraria  un  numero  de  argumentos  desconocidos,  cuyos  nombres  no  se  conocen, 
hasta  en  tiempos  de  ejecucion.  Con  un  simple  asterisco  en  la  parte  superior  del 
parametro,  definimos  cualquier  argumento  posicional,  por  lo  que  la  funcion  se 
comportara  como  una  tupla.  Si  usamos  dos  asteriscos  en  la  parte  superior  del 
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parametro  en  la  definition  de  la  funcion,  cualquier  argumento  clave que  pasemos  a la 
funcion  se  comportara  como  un  diccionario. 

Por  ejemplo,  con  esta  funcion: 

def  vista(*args,  **kwargs): 

print  ("Los  argumentos  posicionales  son:") 
print  (args) 

print  ("Los  argumentos  clave  son:") 
print  (kwargs) 

Por  convention  *args  se  refiere  a los  parametros  posicionales,  mientras  que 
**kwargs  se  refiere  a los  argumentos  clave  en  una  funcion.  Esta  es  la  forma  en  que 
trabajaria: 

»>  vista(l,  2,  3) 

Los  argumentos  posicionales  son: 

(1,  2,  3) 

Los  argumentos  clave  son: 

{} 

»>  vista(l,  2,  name-Adrian’,  framework- Django’) 

Los  argumentos  posicionales  son: 

(1.2) 

Los  argumentos  clave  son: 

{’framework’:  ’Django’,  ’name’:  ’Adrian’} 


Volviendo  a dividir_vista(),  puedes  usar  *args  y ** kwargs  para  aceptar  cualquiera  de 
los  argumentos  en  la  funcion  y pasarselos  a la  vista  apropiada.  Pero  antes  de  hacer 
esto,  es  necesario  llamar  a kwargs.popO  para  obtener  los  argumentos  GET  y POST,  si 
estan  disponibles.  (Usamos  pop()  con  un  valor  predeterminado  y None  para  evitar  un 
error  del  tipo  KeyError si  uno  de  los  otros  no  esta  definido.) 

Empacando  Funciones  de  Vista 

Nuestro  truco  final  toma  la  ventaja  de  las  tecnicas  avanzadas  de  Python.  Digamos 
que  encontramos  un  monton  de  codigo  repetitivo  a lo  largo  de  varias  vistas,  como  en 
este  ejemplo: 

def  vistal(request): 

if  not  request. user. is_authenticated(): 

return  HttpResponseRedirect(’/accounts/login/’) 

# ... 

return  render(request,  ’plantillal.html’) 

def  vista2(request): 

if  not  request. user. is_authenticated(): 

return  HttpResponseRedirect(’/accounts/login/’) 

# ... 

return  render(request,  ’plantilla2.html’) 

def  vista3(request): 

if  not  request.user.is_authenticated(): 

return  HttpResponseRedirect(’/accounts/login/’) 

# ... 

return  render(request,  plantilla3.html’) 
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Tenemos  aqui,  que  cada  vista  empieza  comprobando  que  requestuser  este 
autentificado  - estos  es,  que  el  usuario  actual  se  haya  identificado  correctamente  en 
el  sitio  -si  no  se  redirecciona  a /accounts /login/.  (Observa  que  aun  no  cubrimos 
request.user  -El  cual  veremos  en  el  capitulol4  pero  tal  como  imaginas  request.user 
representa  al  usuario  actual,  ya  sea  anonimo  o registrado.) 

Seria  agradable  si  quitaramos  un  poco  de  codigo  repetitivo  de  cada  una  de  estas 
vistas,  simplemente  marcandolas  como  vistas  que  requieren  de  autentiflcacion. 
Podemos  hacer  esto  haciendo  un  wrapper  o un  contenedor  que  encapsule  estas 
funcionalidades.  Tomate  un  momento  para  estudiar  lo  siguiente: 

def  requierejogin(view): 

def  vista_nueva(request,  *args,  **kwargs): 
if  not  request. user. is_authenticated(): 

return  HttpResponseRedirect(’/accounts/login/’) 
return  view(request,  *args,  **kwargs) 
return  vista_nueva 

La  funcion  requierejogin,  toma  una  funcion  vista  (view)  y retorna  una  nueva 
funcion  vista  (vista_nueva).  La  nueva  funcion  vista_nueva  esta  definida  dentro  de 
requierejogin  y maneja  la  logica  comprobando  que  request.user.is_authenticated() 
(el  usuario  este  identificado)  y delegandolo  a la  vista  original  (view). 

Ahora,  podemos  remover  la  comprobacion  if  not  request.user.is_authenticated() 
de  nuestras  vistas  y simplemente  envolviendolas  con  requierejogin  en  nuestra 
URLconf: 

from  django.conf.urls  import  urls 

from  .views  import  requierejogin,  vistal,  vista2,  vista3 

urlpatterns  = [ 

url(r’Avistal/$’,  requierejogin(vistal)), 
url(r’Avista2/$’,  requiereJogin(vista2)), 
u rl (r ’ Avi sta3/$’ , req u iere J og i n (vi sta3)) , 

] 


Esto  tiene  el  mismo  efecto  que  el  codigo  anterior,  pero  con  menos  codigo 
redundante.  Acabamos  de  crear  una  agradable  funcion  generica  - requierejogin () 
que  podemos  usar  para  envolver  o contener  (wrapping)  cualquier  vista,  para  hacer 
que  esta  requiera  autentificacion. 

Incluyendo  otras  URLconfs 

Si  tu  intencion  es  que  tu  codigo  sea  usando  en  multiples  sitios  implementados  con 
Django,  debes  considerar  el  organizar  tus  URLconfs  en  una  manera  que  permita  el 
uso  de  inclusiones. 

Una  URLconf  puede,  en  cualquier  punto,  “incluir”  otros  modulos  URLconf.  Esto 
se  trata,  en  esencia,  de  “enraizar”  un  conjunto  de  URLs  debajo  de  otras.  Por  ejemplo, 
esta  URLconf  incluye  otras  URLconfs: 

from  django.conf.urls  import  include,  url 

urlpatterns  = [ 

url(r’Aweblog/’,  include(’misitio. blog. urls’)), 
url(r’Afotos/’,  include(’misitio.fotos.urls’)), 
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url(r’Aacerca/$’,  ’misitio.views.acerca’), 

] 


Existe  aqui  un  detalle  importante:  en  este  ejemplo,  la  expresion  regular  que  apunta 
a un  include  ()  no  tiene  un  $ (caracter  que  coincide  con  un  fin  de  cadena)  pero  si 
incluye  una  barra  al  final.  Cuando  Django  encuentra  include!),  elimina  todo  el 
fragmento  de  la  URL  que  ya  ha  coincidido  hasta  ese  momento  y envia  la  cadena 
restante  a la  URLconf  incluida  para  su  procesamiento  subsecuente. 

Continuando  con  este  ejemplo,  esta  es  la  URLconf  para  misitio.blog.urls: 

from  django.conf.urls  import  url 

url  patterns  = [ 

url(r’A(\d\d\d\d)/$’,  'misitio. blog. views. entrada_ano’), 
url(r’A(\d\d\d\d)/(\d\d)/$’,  ’misitio. blog. views. entrada_mes’), 

] 


Con  esas  dos  URLconfs,  veremos  aqui  como  serian  manejadas  algunas  peticiones 
de  ejemplo: 

Con  una  peticion  a /weblog/2007/:  en  la  primera  URLconf,  el  patron  r'Aweblog/' 
coincide.  Debido  a que  es  un  include (),  Django  quita  todo  el  texto  coincidente,  que 
en  este  caso  es  'weblog/'.  La  parte  restante  de  la  URL  es  2007/,  la  cual  coincide  con  la 
primera  linea  en  la  URLconf  misitio.blog.urls. 

Con  una  peticion  a /weblog/ /2007/:  En  la  primera  URLconf,  el  patron  r'Aweblog/' 
coincide. 

Debido  a que  es  un  include!),  Django  quita  todo  el  texto  coinciente,  que  en  este 
caso  es  weblog/.  La  parte  restante  de  la  URL  es  120071  (con  una  barra  inicial),  la  cual 
no  coincide  con  ninguna  de  las  lineas  en  la  URLconf  misitio.blog.urls. 

/acerca/:  Este  coincide  con  el  patron  de  la  vista  misitio.views.acerca  en  la  primera 
URLconf,  demostrando  que  puedes  combinar  patrones  include!)  con  patrones  no 
include!). 

Otra  posibilidad  para  incluir  patrones  adicionales  en  una  URL,  es  usando  una  lista 
de  instancias  de  la  url().  Por  ejemplo,  considera  esta  URLconf.: 

from  django.conf.urls  import  include,  url 
from  apps.main  import  views  as  vista_principal 

from  credito  import  views  as  vista_credito 

patrones_extra  = [ 

url(r’Areportes/(?P<id>[0-9]+)/$’,  vista_credito.reportes), 
url(r’Acargos/$’,  vista_credito. cargos), 

] 

urlpatterns  = [ 

url(r’A$’,  vista_principal. indice), 
url(r’Aayuda/’,  include(  apps.ayuda.urls’)), 
url(r’Acredito/’,  include(patrones_extra)), 

] 


En  este  ejemplo  la  URL  / credito /reportes/,  sera  manejada  por  la  vista 
vista_credito . reportes  0 . 
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Esto  tambien  puede  ser  usado  para  remover  redundancia  en  las  URLconfs, 
mediante  un  simple  prefijo  en  un  patron  usado  repetidamente.  Por  ejemplo, 
considera  esta  URLconf: 

from  django.conf.urls  import  url 
from  . import  views 

urlpatterns  = [ 

url(r’A(?P<pagina_slug>\w+)-(?P<pagina_id>\w+)/historia/$’,  views. historia), 
url(r’A(?P<pagina_slug>\w+)-(?P<pagina_id>\w+)/editar/$’,  views.editar), 
url(r’A(?P<pagina_slug>\w+)-(?P<pagina_id>\w+)/discusiones/$’, 
views. discusiones), 

url(r’A(?P<pagina_slug>\w+)-(?P<pagina_id>\w+)/permisos/$’,  views. permisos), 

] 


Podemos  perfeccionar  esta  URLconf  declarando  un  prefijo  comun  una  vez, 
agrupando  los  sufijos  que  tienen  la  misma  ruta  y excluyendo  los  que  son  diferentes: 

from  django.conf.urls  import  include,  url 
from  . import  views 

urlpatterns  = [ 

url(r’A(?P<pagina_slug>\w+)-(?P<pagina_id>\w+)/’,  include([ 
url(r’Ahistoria/$’,  views. historia), 
url(r’Aeditar/$’,  views.editar), 
url(r’Adiscusiones/$’,  views. discusiones), 
url(r’Apermisos/$’,  views. permisos), 

]))■ 

] 

Como  trabajan  los  parametros  capturados  con  include() 

Una  URLconf  incluida  recibe  todo  parametro  que  se  haya  capturado  desde  las 
URLconf  padre,  por  ejemplo: 


root  urls.py 


from  django.conf.urls  import  url 
urlpatterns  = [ 

url(r’A(?P<username>\w+)/blog/’,  include(’misitio.urls.blog’)), 

] 


misitio/urls/blog.py 


from  django.conf.urls  import  url 
urlpatterns  = [ 

url(r’A$’,  ’misitio.views.indice_blog’), 
url(r’Aarchivos/$’,  ’misitio. views. archivos_blog’), 

] 


En  este  ejemplo,  la  variable  capturada  usernameO  es  pasada  a la  URLconf  incluida 
y,  por  lo  tanto  es  pasada  a todaslas  funciones  vista  en  dicha  URLconf. 

Nota  que  los  parametros  capturados  son  pasados  siempre  a todas  las  lineas  en  la 
URLconf  incluida,  con  independencia  de  si  la  vista  realmente  acepta  estos 
parametros  como  validos.  Por  esta  razon  esta  tecnica  solamente  es  util  si  estas  seguro 
de  que  cada  vista  en  la  URLconf  incluida  acepta  los  parametros  que  le  estas  pasando. 
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Como  funcionan  las  opciones  extra  de  URLconf  con  include() 

De  manera  similar,  puedes  pasar  opciones  extra  de  URLconf  a includeO  asi  como 
puedes  pasar  opciones  extra  de  URLconf  a una  vista  normal  - como  un  diccionario. 
Cuando  haces  esto,  las  opciones  extra  seran  pasadas  a to  das  las  lineas  en  la  URLconf 
incluida. 

Por  ejemplo,  los  siguientes  dos  conjuntos  de  URLconfs  son  funcionalmente 
identicos. 

1.  Conjunto  uno: 


urls.py 


from  django.conf.urls  import  url 
urlpatterns  = [ 

(r’Ablog/’,  include(’url-interna’),  {’blogid’:  3}), 

] 


url-interna.py 


from  django.conf.urls  import  url 
urlpatterns  = [ 

(r’Aarchivos/$\  ’misitio.views.archivos’), 
(r’Aacerca/$\  ’misitio.views.acerca’), 
(r’Arss/$\  ’misitio.views.rss’), 

] 

2.  Conjunto  dos: 


urls.py 


from  django.conf.urls  import  url 
urlpatterns  = [ 

(r’Ablog/\  include(’url-interna’)), 

} 


url-interna.py 


from  django.conf.urls  import  url 
urlpatterns  = [ 

(r’Aarchivos/$\  ’misitio.views.archivos’,  {’blogid’:  3}), 

(r’Aacerca/$\  misitio.views.acerca’,  {’blogid’:  3}), 

(r’Arss/$’,  ’misitio.views.rss',  {’blogid’:  3}), 

] 

Como  en  el  caso  de  los  parametros  capturados  (sobre  los  cuales  se  explico  en  la 
section  anterior),  las  opciones  extra  se  pasaran  siempre  a todas  las  URLconf 
incluidas,  sin  importar  si  la  vista,  realmente  acepta  estas  opciones  como  validas.  Por 
esta  razon  esta  tecnica  es  util  solo  si  estas  seguro  que  todas  las  vistas  en  la  URLconf 
incluida  aceptan  las  opciones  extra  que  les  estas  pasando. 
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Resolution  inversa  de  URLs 

Una  necesidad  muy  comun  al  trabajar  en  un  proyecto  Django  es  la  posibilidad  de 
obtener  URLs  finales,  para  incrustar  en  el  contenido  generado  (vistas  y URLs  activas, 
asi  como  URLs  para  mostrar  a los  usuarios,  etc.)  o para  manejar  el  flujo  de 
navegacion  de  el  lado  del  servidor  (tal  como  redirecionamientos,  etc.) 

Es  altamente  recomendable  evitar  codificar  en  duro  las  URLs(ya  que  esta  serfa  una 
estrategia  muy  laboriosa,  propensa  a errores  y poco  escalable)  o tener  que  idear 
mecanismos  para  generar  URLs  que  sean  paralelas  al  diseno  descrito  por  la  URLconf, 
algo  semejante  podria  echar  a perder  las  URLs  en  algun  punto. 

En  otras  palabras,  es  necesario  usar  un  mecanismo  DRY  (no  te  repitas).  Entre  otras 
ventajas  permitiria  la  evolution  del  diseno  de  URL  sin  tener  que  explorar  en  todas 
partes  del  codigo  fuente,  buscando  y remplazando  URLs  obsoletas. 

Como  punto  de  partida  para  disenar  una  URL,  podemos  empezar  usando  la 
information  disponible,  como  puede  ser  la  identification  (el  nombre)  de  la  vista  a 
cargo  de  manejar  la  URL,  otra  pieza  de  information  necesaria  que  podemos  anticipar 
son  los  tipos  (posicional,  palabra  clave)  y los  valores  y argumentos  de  la  vista,  para 
tomar  en  cuenta  en  la  URL. 

Django  ofrece  una  solution  semejante  al  mapear  una  URL,  unicamente  en  un  solo 
lugar.  Solo  la  defines  en  la  URLconf  y entonces  puede  usarla  en  ambas  direcciones. 
Funciona  de  dos  formas: 

1.  La  primera  forma  comienza  con  una  petition  del  usuario/navegador,  este 
llama  a la  vista  correcta  de  Django  y provee  cualquier  argumento  que  pueda 
necesitar  asi  como  los  valores  extraidos  del  URL. 

2.  La  segunda  forma  comienza  con  la  identification  de  la  vista  correspondiente 
de  Django  mas  los  valores  de  los  argumentos  que  le  son  pasados,  obtenidos  de 
la  URL  asociada. 

El  primero  es  el  usado  en  las  discusiones  previas,  el  segundo  es  llamado  resolution 
inversa  de  URLs,  busqueda  inversa  de  URL  cointidentias  inversas  de  URLs  o 
simplemente  URL  inversa. 

Django  proporciona  herramientas  para  optimizar  las  coincidencias  de  URL 
inversas  en  las  distintas  capas  donde  sean  necesarios. 

■ En  las  plantillas:  Usando  la  etiqueta  de  plantillas  url 

■ En  el  codigo  Python:  Usando  la  funcion  django.core.urlresolvers.reverse 

■ En  codigo  de  alto  nivel,  para  relacionar  el  manejo  de  URLs  de  instancias  de 
modelos:  por  ejemplo  el  metodo  get_absolute_url  en  los  modelos. 

Ejemplos 

Considera  esta  entrada  de  una  URLconf,  a la  que  le  hemos  agregado  un  nombre  al 
patron  URL,  llamado  ‘libros-anuales’,  asi: 

from  django.conf.urls  import  url 
from  biblioteca  import  views 

urlpatterns  = [ 

#... 

url(r’Alibros/([0-9]{4})/$’,  views. libros_anuales,  name- libros-anuales’), 

#... 


] 
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De  acuerdo  al  diseno,  la  URL  para  la  entrada  correspondiente  al  ano  nnnn  es 
/libros/nnnn/. 

Para  obtener  lo  mismo  en  la  plantilla  usamos  este  codigo: 

<a  href="{%  url  ’libros-anuales’  2014  %}">Libros  del  2014</a> 

{#  o sin  el  ano  en  el  contexto  de  la  variable  de  la  plantilla:  #} 

<ul> 

{%  for  ano  in  lista_anual  %} 

<li><a  href="{%  url  ’libros-anuales’  ano  %}">{{  ano }}  Libros</a></li> 

{%  endfor  %} 

</ul> 

O en  el  codigo  Python: 

from  django.core.urlresolvers  import  reverse 
from  django.http  import  HttpResponseRedirect 

def  redireccionar_libros_anuales(request): 

# ... 

year  = 2014 

# ... 

return  HttpResponseRedirect(reverse('libros-anuales',  args=(year,))) 


<j,Que  sigue? 

Uno  de  los  principales  objetivos  de  Django  es  reducir  la  cantidad  de  codigo  que  los 
desarrolladores  deben  escribir  y en  este  capitulo  hemos  sugerido  algunas  formas  en 
las  cuales  se  puede  reducir  el  codigo  de  las  vistas  y las  URLconfs,  proporcionandote 
muchas  de  las  ventajas,  tips  y trucos  para  vistas  y URLconfs,  en  el  capitulo  9,  le 
daremos  este  tratamiento  avanzado  al  sistema  de  plantilla  de  Django. 


CAPITULO  9 


Planti  I las  avanzadas 


^\unque  la  mayor  parte  de  tu  interaction  con  el  sistema  de  plantillas  ( templates ) 
de  Django  sera  en  el  rol  de  autor,  probablemente  querras  algunas  veces  modificar  y 
extender  el  sistema  de  plantillas  - asi  sea  para  agregar  funcionalidad,  o para  hacer  tu 
trabajo  mas  facil  de  alguna  otra  manera. 

Este  capitulo  se  adentra  en  el  sistema  de  plantillas  de  Django,  cubriendo  todo  lo 
que  necesitas  saber,  ya  sea  por  si  planeas  extender  el  sistema,  o por  si  solo  eres 
curioso  acerca  de  su  funcionamiento.  Ademas  cubre  la  caracteristica  de  auto-escape, 
medida  de  seguridad  que  seguramente  notaras  con  el  paso  del  tiempo  si  continuas 
usando  Django. 

Si  estas  tratando  de  utilizar  el  sistema  de  plantillas  de  Django  como  parte  de  otra 
aplicacion,  es  decir,  sin  el  resto  del  framework,  asegurate  de  leer  la  seccion 
“Configurando  el  Sistema  de  plantillas  en  modo  autonomo”  mas  adelante  en  este 
mismo  capitulo. 

Revision  del  lenguaje  de  plantillas 

Primero,  vamos  a recordar  algunos  terminos  presentados  en  el  capitulo  4. 

■ Una  plantilla  es  un  documento  de  texto,  o un  string  normal  de  Python 
marcado  con  la  sintaxis  especial  del  lenguaje  de  plantillas  de  Django.  Una 
plantilla  puede  contener  etiquetas  de  bloque  {block  tags)  y variables. 

■ Una  etiqueta  de  bloque  es  un  simbolo  dentro  de  una  plantilla  que  hace  algo. 
Esta  definicion  es  asi  de  vaga  a proposito.  Por  ejemplo,  una  etiqueta  de  bloque 
puede  producir  contenido,  servir  como  estructura  de  control  (una  sentencia  if 
o un  loop  for),  obtener  contenido  de  la  base  de  datos,  o habilitar  acceso  a 
otras  etiquetas  de  plantilla. 

Las  etiquetas  de  bloque  deben  ser  rodeadas  por  {%  y %} 

{%  if  isjoggedjn  %} 

jGracias  por  identificarte! 

{%  else  %} 

Por  favor  identificarte. 

{%  endif  %} 

■ Una  variable  es  un  simbolo  dentro  de  una  plantilla  que  emite  un  valor. 

Las  etiquetas  de  variable  deben  ser  rodeadas  por  {{ y }}: 

Mi  nombre  es  {{  nombre  }}  Mis  apellidos  son  {{  apellidos  }}. 

■ Un  contexto  es  un  mapeo  entre  nombres  y valores  (similar  a un 
diccionario  de  Python)  que  es  pasado  a una  plantilla. 
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Una  plantilla  renderiza  un  contexto  reemplazando  los  “huecos”  que  dejan  las 
variables  por  valores  tornados  del  contexto  y ejecutando  todas  las  etiquetes  de 
bio  que. 

El  resto  de  este  capitulo  discute  las  distintas  maneras  de  extender  el  sistema  de 
plantillas.  Aunque  primero,  debemos  dar  una  mirada  a algunos  conceptos  internos 
que  quedaron  fuera  del  capitulo  4 por  simplicidad. 

Procesadores  y peticiones  de  contexto 

Cuando  una  plantilla  debe  ser  renderizada,  necesita  un  contexto.  Usualmente  este 
contexto  es  una  instancia  de  django.template.Context,  pero  Django  tambien  provee 
una  subclase  especial:  django.template.RequestContext  que  actua  de  una  manera 
levemente  diferente.  RequestContext  agrega  muchas  variables  al  contexto  de  nuestra 
plantilla  - cosas  como  el  objeto  HttpRequest  o information  acerca  del  usuario  que 
esta  siendo  usado  actualmente.  El  atajo  render!)  crea  un  RequestContext  a menos 
que  explicitamente  se  le  pase  una  instancia  de  contexto  diferente. 

Usa  RequestContext  cuando  no  quieras  especificar  el  mismo  conjunto  de  variables 
una  y otra  vez  en  una  serie  de  plantillas.  Por  ejemplo,  considera  estas  dos  vistas: 

from  django. template  import  loader,  Context 

def  vista_l(request): 

# ... 

t = loader. get_template(’plantilla.html’) 
c = Context({ 

’aplicacion:  Biblioteca , 

’usuario’:  request.user, 

’direccionjp’:  request. META[’REMOTE_ADDR’], 

’mensaje’:  ’Soy  una  vista.’ 

}) 

return  t.render(c) 

def  vista_2(request): 

# ... 

t = loader.get_template(’plantilla2.html) 
c = Context({ 

’aplicacion:  Biblioteca 
’usuario’:  request.user, 

’direccionjp’:  request. META[’REMOTE_ADDR’], 

’mensaje’:  ’Soy  otra  vista.’ 

}) 

return  t.render(c) 

A proposito  no  hemos  usado  el  atajo  render!)  en  estos  ejemplos  - manualmente 
cargamos  las  plantillas,  construimos  el  contexto  y renderizamos  las  plantillas. 
Simplemente  por  claridad,  estamos  demostrando  todos  los  pasos  necesarios. 

Cada  vista  pasa  las  mismas  tres  variables  - aplicacion,  usuario  y directamente  Jp  a 
la  plantilla.  ^No  serfa  bueno  poder  eliminar  esa  redundancia? 

Las  peticiones  de  contexto  (RequestContext)  y los  procesadores  de  contexto 
(Context  Processors)  fueron  creados  para  resolver  este  problema.  Los  procesadores 
de  contexto  te  permiten  especificar  un  numero  de  variables  que  son  incluidas 
automaticamente  en  cada  contexto  - sin  la  necesidad  de  tener  que  hacerlo 
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manualmente  en  cada  llamada  a render().  El  secreto  esta  en  utilizar  RequestContext 
en  lugar  de  Context  cuando  renderices  una  plantilla. 

La  forma  de  nivel  mas  bajo  de  usar  procesadores  de  contexto  es  crear  algunos  de 
ellos  y pasarlos  a RequestContext.  A continuation  mostramos  como  el  ejemplo 
anterior  puede  lograrse  utilizando  procesadores  de  contexto: 

from  django. template  import  loader,  RequestContext 

def  custom_proc(request): 

"Un  procesador  de  contexto  que  provee  ’aplicacion’,  ’usuario’  y’direcccionjp’." 
return  { 

’aplicacion:  Biblioteca, 

’usuario’:  request.user, 

’direccionjp’:  request. META[’REMOTE_ADDR’], 

} 

def  vista_l(request): 

# ... 

t = loader. get_template(’plantillal.html) 
c = RequestContext(request,  {’mensaje’:  ’Soy  la  vista  1.’}, 
processors=[custom_proc]) 
return  t.render(c) 

def  vista_2(request): 

# ... 

t = loader. get_template(’plantilla2.html) 
c = RequestContext(request,  {’mensaje’:  ’Soy  la  vista  2. }, 
processors=[custom_proc]) 
return  t.render(c) 

Inspeccionemos  paso  a paso  este  codigo: 

■ Primero,  defmimos  una  funcion  custom_proc.  Este  es  un  procesador  de 
contexto  - toma  un  objeto  ElttpRequest  y devuelve  un  diccionario  con 
variables  a usar  en  el  contexto  de  la  plantilla.  Eso  es  todo  lo  que  hace. 

■ Elemos  cambiado  las  dos  vistas  para  que  usen  RequestContext  en  lugar  de 
Context.  Elay  dos  diferencias  en  cuanto  a como  el  contexto  es  construido. 
Uno,  RequestContext  requiere  que  el  primer  argumento  sea  una  instancia 
de  ElttpRequest  - la  cual  fue  pasada  a la  vista  en  primer  lugar  (request). 
Dos,  RequestContext  recibe  un  parametro  opcional  processors,  el  cual  es 
una  lista  o una  tupla  de  funciones  procesadoras  de  contexto  a utilizar.  En 
este  caso,  pasamos  custom_proc,  a nuestro  procesador  de  contexto 
definido  previamente. 

■ Ya  no  es  necesario  en  cada  vista  incluir  aplicacion,  usuario  y direccion_ip 
cuando  construimos  el  contexto,  ya  que  ahora  estas  variables  son  provistas 
por  custom_proc. 

■ Cada  vista  aun  posee  la  flexibilidad  como  para  introducir  una  o mas 
variables  en  el  contexto  de  la  plantilla  si  es  necesario.  En  este  ejemplo,  la 
variable  de  plantilla  mensaje  es  creada  de  manera  diferente  en  cada  una  de 
las  vistas. 
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En  el  capltulo  4,  presentamos  el  atajo  renderO,  el  cual  nos  ahorra  tener  que  llamar 
a loader.  get_templateO,  luego  crear  un  Context  y ademas,  llamar  al  metodo  renderO 
en  la  plantilla.  Para  demostrar  el  funcionamiento  a bajo  nivel  de  los  procesadores  de 
contexto,  en  los  ejemplos  anteriores  no  hemos  utilizado  renderO,  pero  es  posible  - y 
preferible  utilizar  los  procesadores  de  contexto  junto  a renderO-  Esto  lo  logramos 
mediante  el  argumento  context_instance  de  la  siguiente  manera: 

from  django. shortcuts  import  render 

from  django. template  import  RequestContext 

def  custom_proc(request): 

" Un  procesador  de  contexto  que  provee  ’aplicacion’,  ’usuario’  y ’directamentejp’." 
return  { 

’aplicacion:  Bibliotecai 
’usuario’:  request.user, 

’direccionjp’:  request. META[’REMOTE_ADDR’], 

} 

def  vista2(request): 

# ... 

return  render(request,  ’plantillal.html’, 

{’mensaje’:  ’Soy  la  vista  1.’}, 

context_instance=RequestContext(request,  processors=[custom_proc])) 

def  vista2(request): 

# ... 

return  render(request,  ’template2.html’, 

{’mensaje’:  ’Soy  la  vista  2.’}, 

context_instance=RequestContext(request,  processors=[custom_proc])) 

Aquf,  hemos  logrado  reducir  el  codigo  para  renderizar  las  plantillas  en  cada  vista  a 
una  sola  lfnea. 

Esto  es  una  mejora,  pero,  evaluando  la  concision  de  este  codigo,  debemos  admitir 
que  hemos  logrado  reducir  la  redundancia  en  los  datos  (nuestras  variables  de 
plantilla),  pero  aun  asi,  estamos  especificando  una  y otra  vez  nuestro  contexto.  Es 
decir,  hasta  ahora  el  uso  de  procesadores  de  contexto  no  nos  ahorra  mucho  codigo,  si 
tenemos  que  escribir  procesadores  constantemente. 

Por  esta  razon,  Django  admite  el  uso  de  procesadores  de  contexto  globales.  El 
parametro  de  configuracion  TEMPLATE_CONTEXT_PROCESSORS  designa  cuales 
seran  los  procesadores  de  contexto  que  deberan  ser  aplicados  siempre  a 
RequestContext.  Esto  elimina  la  necesidad  de  especificar  processors  cada  vez  que 
utilizamos  RequestContext. 

TEMPLATE_CONTEXT_PROCESSORS  tiene,  por  omision,  el  siguiente  valor: 

TEMPLATE_CONTEXT_PROCESSORS  = ( 

'django. core. context_processors.auth’, 

’django. core. context_processors. debug’, 

'django. core. context_processors.il8n’, 

'django. core. context_processors.  media’, 

) 


Este  parametro  de  configuracion  es  una  tupla  de  funciones  que  utilizan  la  misma 
interfaz  que  nuestra  funcion  custom_proc  utilizada  previamente  - funciones  que 
toman  un  objeto  HttpRequest  como  primer  argumento,  y devuelven  un  diccionario 
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de  items  que  seran  incluidos  en  el  contexto  de  la  plantilla.  Ten  en  cuenta  que  los 
valores  en  TEMPLATE_CONTEXT_PROCESSORS  son  especificados  como  cadenas,  lo 
cual  significa  que  estos  procesadores  deberan  estar  en  algun  lugar  dentro  de  tu 
PYTHONPATH  (para  poder  referirse  a ellos  desde  el  archivo  de  configuracion) 

Estos  procesadores  de  contexto  son  aplicados  en  orden,  es  decir,  si  uno  de  estos 
procesadores  anade  una  variable  al  contexto  y un  segundo  procesador  anade  otra 
variable  con  el  mismo  nombre,  entonces  la  segunda  sobre-escribira  a la  primera. 

Django  provee  un  numero  de  procesadores  de  contexto  simples,  entre  ellos  los  que 
estan  activos  por  defecto. 

django.core.context_processors.auth 

Si  TEMPLATE_CONTEXT_PROCESSORS  contiene  este  procesador,  cada 
RequestContext  contendra  las  siguientes  variables: 

■ user.  Una  instancia  de  django.contrib.auth.models.User  representando  al 
usuario  actualmente  autenticado  (o  una  instancia  de  AnonymousUser  si  el 
cliente  no  se  ha  autenticado  aun). 

■ messages-.  Una  lista  de  mensajes  (como  string}  para  el  usuario  actualmente 
autenticado.  Detras  del  telon,  esta  variable  llama  a 
request.user.get_and_delete_messages()  para  cada  request.  Este  metodo 
colecta  los  mensajes  del  usuario,  y luego  los  borra  de  la  base  de  datos. 

■ perms:  Instancia  de  django.core.context_processors.PermWrapper,  la  cual 
representa  los  permisos  que  posee  el  usuario  actualmente  autenticado. 

En  el  capitulo  14  encontraras  mas  informacion  acerca  de  usuarios,  permisos  y 
mensajes. 

django.core.context_processors.debug 

Este  procesador  agrega  informacion  de  depuration  a la  capa  de  plantillas.  Si 
TEMPLATE_CONTEXT_PROCESSORS  contiene  este  procesador,  cada 
RequestContext  contendra  las  siguientes  variables: 

■ debug:  El  valor  del  parametro  de  configuracion  DEBUG  (True  o False).  Esta 
variable  puede  usarse  en  las  plantillas  para  saber  si  estas  en  modo  de 
depuration  o no. 

■ sql_queries-.  Una  lista  de  diccionarios  {'sql': ...,  ’time’: ...}  representando  todas 
las  consultas  SQL  que  se  generaron  durante  la  petition  ( request}  y cuanto 
duraron.  La  lista  esta  ordenada  respecto  a cuando  fue  ejecutada  cada 
consulta. 

Como  la  informacion  de  depuration  es  sensible,  este  procesador  de  contexto  solo 
agregara  las  variables  al  contexto  si  las  dos  siguientes  condiciones  son  verdaderas. 

■ El  parametro  de  configuracion  DEBUG  es  True 

■ La  solicitud  ( request j viene  de  una  direction  IP  listada  en  el  parametro  de 
configuracion 
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INTERNAL_IPS:  Los  lectores  astutos  se  daran  cuenta,  que  si  la  variable  de 
plantilla  debug  tiene  el  valor  False,  las  demas  variables  de  plantillas  que  dependen 
de  debug,  no  podran  cargarse  en  primer  lugar. 


django.core.context_processors.il8n 

Si  este  procesador  esta  habilitado,  cada  RequestContext  contendra  las  siguientes 
variables: 

■ LANGUAGES'.  El  valor  del  parametro  de  configuracion  LANGUAGES. 

■ LANGUAGE_CODE\  request.LANGUAGE_CODE  si  existe;  de  lo  contrario,  el 
valor  del  parametro  de  configuracion  LANGUAGE_CODE. 

En  el  Apendice  D se  especiflca  mas  informacion  sobre  estos  parametros. 

django.core.context_processors.request 

Si  este  procesador  esta  habilitado,  cada  RequestContext  contendra  una  variable 
request,  la  cual  es  el  actual  objeto  HttpRequest.  Observa  que  este  procesador  no  esta 
habilitado  por  defecto;  tu  tienes  que  activarlo. 

Tal  vez  quieras  usarlo,  si  necesitas  que  tus  plantillas  tengan  acceso  a los  atributos 
de  la  actual  HttpRequest  tal  como  la  direccion  IP: 

{{ request.REMOTE_ADDR }} 

Consideraciones  para  escribir  tus  propios  procesadores  de  contexto 

Algunos  puntos  a tener  en  cuenta: 

■ Cada  procesador  de  contexto  debe  ser  responsable  por  la  minima  cantidad  de 
funcionalidad  posible.  Usar  muchos  procesadores  es  algo  sencillo,  es  por  eso 
que  dividir  la  funcionalidad  de  tu  procesador  de  manera  logica  puede  ser  util 
para  poder  reutilizarlos  en  el  futuro. 

■ Ten  presente  que  cualquier  procesador  de  contexto  en 
TEMPLATE_CONTEXT_PROCESSORS  estara  disponible  en  cada  plantilla  cuya 
configuracion  este  dictada  por  ese  archivo  de  configuracion,  asi  que  trata  de 
seleccionar  nombres  de  variables  con  pocas  probabilidades  de  entrar  en 
conflicto  con  nombre  de  variables  que  tus  plantillas  pudieran  usar  en  forma 
independiente.  Como  los  nombres  de  variables  son  sensibles  a 
mayusculas/minusculas  no  es  una  mala  idea  usar  mayusculas  para  las 
variables  provistas  por  un  procesador. 

■ No  importa  donde  residan  en  el  sistema  de  archivos,  mientras  se  hallen  en  tu 
ruta  de  Python  de  manera  que  puedas  incluirlos  en  tu  variable  de 
configuracion  TEMPLATE_CONTEXT_PROCESSORS.  Habiendo  dicho  eso, 
diremos  tambien  que  la  convencion  es  grabarlos  en  un  archivo  llamado 
context_processors.py  ubicado  en  tu  aplicacion  o en  tu  proyecto. 
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Escape  automatico  de  HTML 

Cuando  generamos  HTML  por  medio  de  plantillas,  siempre  existe  el  riesgo  de  incluir 
variables  que  conte ngan  caracteres  que  afecten  la  salida  del  HTML.  Por  ejemplo, 
considera  el  siguiente  fragmento  de  una  plantilla: 

Hola,  {{ nombre }}. 

Esto  parece  inofensivo  al  principio,  ya  que  solo  muestra  el  nombre  de  un  usuario, 
pero  considera  lo  siguiente:  que  pasaria  si  el  usuario  introduce  su  nombre  de  la 
siguiente  manera: 

<script>alert('hola')</script> 

Con  este  valor,  la  plantilla  renderizaria  el  nombre  asi: 

Hola,  <script>alert('hola')</script> 

Lo  cual  daria  como  resultado  que  el  navegador  mostrara  una  caja  de  alerta.  De 
igual  forma,  si  el  nombre  contiene  simbolos  como  este 

<b>usernombre 

Esto  daria  como  resultado  una  plantilla  renderizada  asi: 

Hola,  <b>usernombre 

Lo  cual  a su  vez  daria  como  resultado  que  el  nombre  apareciera  en  negritas. 
Claramente,  no  deberias  confiar  en  todo  lo  que  los  usuarios  suban  ciegamente,  ni 
tampoco  deberias  permitir  que  inserten  datos  directamente  en  las  paginas  web, 
porque  algun  usuario  malicioso  podria  aprovecharse  de  huecos  como  estos,  para 
hacer  cosas  potencialmente  daninas. 

Este  tipo  de  de  riesgos  de  seguridad  es  llamado  ataque  Cross  Site  Scripting  (XSS) 
(Scripting  inter-sitio).  Consulta  el  capitulo  20,  para  conocer  mas  sobre  seguridad. 

Para  evitar  este  problema,  tienes  dos  opciones: 

1.  Uno,  asegurate  de  que  cada  una  de  las  variables  “no  confiables”,  sean  pasadas 
a traves  de  un  filtro  escape,  el  cual  convierte  caracteres  potencialmente 
daninos  en  no  daninos.  Esta  fue  la  solucion  por  defecto  en  Django  durante  los 
primeros  anos,  pero  el  problema  es  que  pone  toda  la  responsabilidad  en  t/que 
como  desarrollador/autor  de  plantillas,  debes  asegurarte  de  escapar  todo.  Es 
facil  olvidar  escapar  datos. 

2.  Dos,  puedes  tomar  ventaja  de  que  Django  automaticamente  escapa  el  HTML. 
El  resto  de  esta  section  describe  como  trabaja  el  auto-escape. 

Por  defecto  en  Django,  cada  plantilla  se  encarga  automaticamente  de  escapar  la 
salida  de  cada  etiqueta  de  variable.  Es  particular  estos  cinco  caracteres  son 
escapados: 

• < es  convertido  a &lt; 

• >es  convertido  a &gt; 

• ' (comillas  simples)  son  convertidas  a &#39; 

• " (comillas  dobles)  son  convertidas  a &quot; 
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• & es  convertido  a &amp; 

De  nuevo,  hacemos  enfasis  en  que  este  comportamiento  se  da  por  defecto.  Si  estas 
usando  el  sistema  de  plantillas,  estas  protegido. 

Como  desactivar  el  escape  automatico 

Si  no  quieres  que  los  datos  sean  escapados  automaticamente  en  el  sitio,  en  algun 
nivel  de  las  plantillas  o a nivel  de  variables,  puedes  desactivar  este  comportamiento 
de  diferentes  formas. 

^Porque  querrias  desactivarlo?  Porque  algunas  veces,  las  variables  de  plantillas 
contienen  datos  que  intentas  renderizar  como  HTML  en  crudo,  en  cuyo  caso 
necesitas  que  el  contenido  no  sea  escapado.  Por  ejemplo,  si  quisieras  almacenar 
algunos  datos  confiables  en  HTML  en  la  base  de  datos  y quisieras  incrustarlos 
directamente  en  la  plantilla  o si  quieres  usar  el  sistema  de  plantillas  para  producir 
texto  que  no  sea  HTML  -Tal  como  un  mensaje  de  email,  para  una  instancia. 

Para  Variables  individuales 

Para  desactivar  el  auto- escape  para  una  variable  individual,  usa  el  filtro  safe: 

• Esto  sera  escapado:  {{  datos  }} 

• Esto  no  sera  escapado  {{  datos|safe  }} 

Piensa  en  safe  como  el  nombre  corto  para  safe  from  further  escaping  o puede  ser 
interpretado  de  forma  segura  como  HTML  En  este  ejemplo,  si  datos  contiene  '<b>',  la 
salida  sera: 

• Esto  sera  escapado:  &lt;b&gt; 

• Esto  no  sera  escapado:  <b> 

Para  bloques  de  plantillas 

Para  controlar  el  auto -escapado  de  una  plantilla,  envuelve  la  plantilla  (o  solo  una 
section  en  particular)  con  la  etiqueta  autoescape,  de  esta  forma: 

{%  autoescape  off  %} 

Hola  {{  nombre  }} 

{%  endautoescape  %} 

La  etiqueta  autoescape  toma  cualquiera  de  estos  argumentos:  on  u off. 
Ocasionalmente,  tal  vez  quieras  forzar  el  auto-escape,  cuando  este  desactivado.  Esta 
es  una  plantilla  de  ejemplo: 

Auto-escape  activado  por  defecto. 

Hola  {{ nombre  }} 

{%  autoescape  off  %} 

Esto  no  sera  auto-escapado:  {{  datos  }}. 

Esto  tampoco:  {{  otros_datos  }} 

{%  autoescape  on  %} 

Auto-escape  aplicado  otra  vez:  {{  nombre  }} 
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{%  endautoescape  %} 

{%  endautoescape  %} 

La  etiqueta  de  auto-escape  pasa  sus  efectos  a las  plantillas  que  extiende,  asi  como  a 
las  plantillas  incluidas  via  la  etiqueta  include,  tal  como  lo  hacen  todos  los  bloques  de 
etiquetas. 

Por  ejemplo: 


base . html 


{%  autoescape  off  %} 

<hl>{%  block  title  %}{%  endblock  %}</hl> 
{%  block  content  %} 

{%  endblock  %} 

{%  endautoescape  %} 


child.html 


{%  extends  "base.html"  %} 

{%  block  title  %}Bienvenidos{%  endblock  %} 

{%  block  content  %}{{ saludo  }}{%  endblock  %} 

Una  vez  que  el  auto-escape  es  desactivado  en  la  plantilla  base,  tambien  puede  ser 
desactivado  en  las  plantillas  hijas,  resultando  en  el  siguiente  HTML  renderizado 
cuando  la  variable  saludo  contiene  la  cadena  <b>Hola!</b>: 

<hl>Bienvenidos</hl> 

<b>jHola!</b> 


NOTA:  En  general,  los  autores  de  plantillas  no  necesitan  preocuparse  por  auto- 
escapar  mucho.  Los  desarrolladores  del  lado  de  Python  (personas  que  escriben  vista 
y filtros  a la  medida)  necesitan  pensar  en  los  casos  en  los  cuales  sus  datos  no  sean 
escapados  y marcarlos  apropiadamente,  pensando  en  la  forma  en  que  trabajan  las 
plantillas. 


Si  estas  creando  plantillas,  para  situaciones  en  las  que  no  estas  seguro  si  el  auto- 
escape esta  activado,  puedes  agregar  un  filtro  escape  a cualquier  variable  que 
necesite  ser  escapada.  Cuando  el  auto-escape  esta  activado,  no  hay  peligro  de  el  filtro 
escape  o del  doble-escapado  de  datos  - el  filtro  escape  no  afecta  las  variables  que  ya 
han  ha  sido  escapadas. 

Escape  automatico  de  cadenas  literales  en  argumentos  de  filtros 

Como  mencionamos  anteriormente,  los  argumentos  de  algunos  filtros  pueden  ser 
cadenas: 

{{  datos|default:"Esta  es  una  cadena  literal." }} 

Todas  las  cadenas  literales  son  insertadas  sin  escape  automatico  en  la  plantilla  - 
actuan  como  si  fueran  pasadas  por  el  filtro  safe.  La  razon  detras  de  todo  esto,  es  que 
los  autores  de  plantillas  tienen  el  control  de  lo  que  pasan  dentro  de  las  cadenas 
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literales,  asi  que  se  aseguran  que  el  texto  sea  escapado  correctamente  cuando  la 
plantilla  es  escrita. 

Por  lo  que  escribirias 

{{  datos  default:"3  &lt;  2" }} 

En  lugar  de: 

{{  datos  default:"3  < 2" }}  <--  j Mai!  No  hagas  esto. 

Esto  no  afecta  el  comportamiento  de  los  datos,  que  provienen  de  la  misma 
variable.  El  contenido  de  las  variable  todavia  es  escapado  automaticamente  si  es 
necesario,  porque  va  mas  alia  de  el  control  del  autor  de  la  plantilla. 

Detalles  internos  de  la  carga  de  plantillas 

En  general  las  plantillas  se  almacenan  en  archivos  en  el  sistema  de  archivos,  pero 
puedes  usar  cargadores  de  plantillas  personalizados  {template  loaders)  para  cargar 
plantillas  desde  otros  origenes. 

Django  tiene  dos  maneras  de  cargar  plantillas: 

■ django. template. loader. get_template (template):  get_template  retorna  la 

plantilla  compilada  (un  objeto  Template)  para  la  plantilla  con  el  nombre 
provisto.  Si  la  plantilla  no  existe,  se  generara  una  excepcion 

TemplateDoesNotExist. 

■ django.  template. loader.select_template(template_nombre_list): 

select_template  es  similar  a get-template,  excepto  que  recibe  una  lista  de 
nombres  de  plantillas.  Retorna  la  primera  plantilla  de  dicha  lista  que  existe.  Si 
ninguna  de  las  plantillas  existe  se  lanzara  una  excepcion 

TemplateDoesNotExist. 

Como  se  vio  en  el  capltulo  4 , cada  una  de  estas  funciones  usan  por  omision  el  valor 
de  la  variable  de  configuracion  TEMPLATE_DIRS  para  cargar  las  plantillas.  Sin 
embargo,  internamente  las  mismas  delegan  la  tarea  pesada  a un  cargador  de 
plantillas. 

Algunos  de  los  cargadores  estan,  de  forma  predeterminada  desactivados,  pero 
puedes  activarlos  editando  la  variable  de  configuracion  TEMPLATE_LOADERS. 

TEMPLATE_LOADERS  debe  ser  una  tupla  de  cadenas,  donde  cada  cadena 
representa  un  cargador  de  plantillas. 

Estos  son  los  cargadores  de  plantillas  incluidos  con  Django: 

■ django. template. loaders. filesystem.load_template_source:  Este  cargador 
carga  plantillas  desde  el  sistema  de  archivos,  de  acuerdo  a TEMPLATE_DIRS. 
Por  omision  esta  activo. 

■ django.  templa  te.  loaders.  app_  directories.  load_  tempi  a te_  so  urce:  Este 

cargador  carga  plantillas  desde  aplicaciones  Django  en  el  sistema  de  archivos. 
Para  cada  aplicacion  en  INSTALLED_APPS,  el  cargador  busca  un  sub- 
directory templates.  Si  el  directorio  existe,  Django  buscara  una  plantilla  en  el 
mismo. 

■ django.  template. loaders,  eggs. load_template_source:  Este  cargador  es 
basicamente  identico  a app_directories,  excepto  que  carga  las  plantillas  desde 
eggs  Python  en  lugar  de  hacerlo  desde  el  sistema  de  archivos.  Por  omision  este 
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cargador  esta  desactivado;  necesitaras  activarlo  si  estas  usando  eggs  para 
distribuir  tu  aplicacion. 

Esto  significa  que  puedes  almacenar  plantillas  en  tus  aplicaciones  individualmente, 
facilitando  la  distribution  de  aplicaciones  Django  con  plantillas  predeterminadas. 

Por  ejemplo  si  INSTALLED_APPS  contiene  ('misitio.blog',  'misitio.musica')  entonces 
get_template('foo.htmr)  buscara  plantillas  en  el  siguiente  orden: 

1.  /ruta/a/misitio/blog/templates/foo.html 

2.  /ruta/a/misitio/musica/templates/foo.html 

Tambien  debes  saber,  que  el  cargador  realiza  una  optimization  cuando  es 
importado  por  primera  vez:  hace  cacheo  de  una  lista  de  paquetes  registrados  en 
INSTALLED_APPS  , buscando  en  el  sub-directorio  templates.  Por  omision  este 
cargador  esta  activado. 

Django  usa  los  cargadores  de  plantillas  en  el  orden  en  el  que  aparecen  en  la 
variable  de  configuracion  TEMPLATE_DIRS.  Usara  cada  uno  de  los  cargadores  hasta 
que  uno  de  los  mismos  tenga  exito  en  la  busqueda  de  la  plantilla. 

Extender  el  sistema  de  plantillas 

Ahora  que  entiendes  un  poco  mas  acerca  del  funcionamiento  interno  del  sistema  de 
plantillas,  echemos  una  mirada  a como  extender  el  sistema  con  codigo  propio. 

La  mayor  parte  de  la  personalization  de  plantillas  se  da  en  forma  de  etiquetas  y / o 
filtros.  Aunque  el  lenguaje  de  plantillas  de  Django  incluye  muchos,  probablemente 
disenaras  tus  propias  bibliotecas  de  etiquetas  y filtros  que  se  adapten  a tus  propias 
necesidades.  Afortunadamente,  es  muy  facil  definir  tu  propia  funcionalidad. 

Crear  una  biblioteca  para  etiquetas 

Ya  sea  que  estes  escribiendo  etiquetas  o filtros  personalizados,  la  primera  tarea  a 
realizar  es  crear  una  biblioteca  para  etiquetas  - un  pequeno  fragmento  de 
infraestructura  con  el  cual  Django  puede  interactuar  (un  directorio). 

La  creation  de  una  biblioteca  para  etiquetas  es  un  proceso  de  dos  pasos: 

■ Primero,  decidir  que  aplicacion  Django  alojara  el  directorio.  Si  has  creado  una 
aplicacion  via  manage. py  startapp  puedes  colocarla  alii,  o puedes  crear  otra 
aplicacion  con  el  solo  fin  de  alojar  la  biblioteca. 

Sin  importar  cual  de  las  dos  rutas  tomes,  asegurate  de  agregar  la  aplicacion  a 
tu  variable  de  configuracion  INSTALLED_APPS.  Explicaremos  esto  un  poco 
mas  adelante. 

■ Segundo,  crea  un  directorio  templatestags  en  el  paquete  de  aplicacion  Django 
apropiado.  Debe  encontrarse  en  el  mismo  nivel  que  models.py,  views.py,  etc. 
Por  ejemplo  mira  el  siguiente  directorio: 

biblioteca/ 

init . py 

admin . py 
forms . py 
models . py 
templates/ 

indice . html 
templatestags/ 
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init . py 

etiquetas . py 
views . py 

Crea  dos  archivos  vacios  en  el  directorio  templatetags:  un  archivo init .py 

(para  indicarle  a Python  que  se  trata  de  un  paquete  que  contiene  codigo 
Python)  y un  archivo  que  contendra  tus  definiciones  personalizadas  de 
etiquetas /filtros.  El  nombre  del  segundo  archivo  es  el  que  usaras  para  cargar 
las  etiquetas  mas  tarde.  Por  ejemplo,  si  tus  etiquetas /filtros  personalizadas 
estan  en  un  archivo  llamado  etiquetas.py,  entonces  deberas  escribir  lo 
siguiente  en  una  plantilla: 

{%  load  etiquetas  %} 

La  etiqueta  {%  load  %}  examina  tu  variable  de  configuration 
INSTALLED_APPS  y solo  permite  la  carga  de  bibliotecas  para  plantillas  desde 
aplicaciones  Django  que  esten  instaladas.  Se  trata  de  una  caracteristica  de 
seguridad;  te  permite  tener  en  cierto  equipo  el  codigo  Python  de  varias 
bibliotecas  para  plantillas  sin  tener  que  activar  el  acceso  a todas  ellas  para 
cada  instalacion  de  Django. 

Si  escribes  una  biblioteca  para  etiquetas  que  no  se  encuentra  atada  a ningun 
modelo/vista  particular  es  valido  y normal  el  tener  un  paquete  de  aplicacion  Django 
que  solo  contiene  un  paquete  templatetags.  No  existen  limites  en  lo  referente  a 
cuantos  modulos  puedes  poner  en  el  paquete  templatetags.  Solo  ten  presente  que 
una  sentencia  {%  load  %}  cargara  etiquetas /filtros  para  el  nombre  del  modulo  Python 
provisto,  no  el  nombre  de  la  aplicacion. 

Una  vez  que  has  creado  ese  modulo  Python,  solo  tendras  que  escribir  un  poquito 
de  codigo  Python,  dependiendo  de  si  estas  escribiendo  filtros  o etiquetas. 

Para  ser  una  biblioteca  de  etiquetas  valida,  el  modulo  debe  contener  una  variable  a 
nivel  del  modulo  llamada  register,  que  sea  una  instancia  de  template.Library.  Esta 
instancia  de  template.Library  es  la  estructura  de  datos  en  la  cual  son  registrados 
todas  las  etiquetas  y filtros. 

Asi  que  inserta  en  la  zona  superior  de  tu  modulo,  lo  siguiente: 
from  django  import  template 
register  = template.  LibraryQ 


Nota:  Para  ver  un  buen  numero  de  ejemplos,  examina  el  codigo  fuente  de  los 
filtros  y etiquetas  incluidos  con  Django.  Puedes  encontrarlos  en 
django/template/defaultfilters.py  y django/template/defaulttags.py, 

respectivamente.  Algunas  aplicaciones  en  django. contrib  tambien  contienen 
bibliotecas  para  plantillas. 


Una  vez  que  hayas  creado  esta  variable  register,  puedes  usarla  para  crear  filtros  y 
etiquetas  para  plantillas. 

Escribir  filtros  de  plantilla  personalizados 

Los  filtros  personalizados  son  solo  funciones  Python  que  reciben  uno  o dos 
argumentos: 


El  valor  de  la  variable  (entrada) 
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■ El  valor  del  argumento,  el  cual  puede  tener  un  valor  por  omision  o puede  ser 
obviado. 

Por  ejemplo,  en  el  filtro  {{  var|foo:"bar"  }}  el  filtro  foo  recibiria  el  contenido  de  la 
variable  var  y el  argumento  "bar". 

Las  funciones  filtro  deben  siempre  retornar  algo.  No  deben  arrojar  excepciones,  y 
deben  fallar  silenciosamente.  Si  existe  un  error,  las  mismas  deben  retornar  la  entrada 
original  o una  cadena  vacia,  dependiendo  de  que  sea  mas  apropiado. 

Este  es  un  ejemplo  de  la  definicion  de  un  filtro: 

def  cortar(value,  arg): 

"Remueva  todos  los  valores  que  concuerdan  con  los 
Argumentos  de  la  cadena  dada" 

return  value. replace(arg,  ”) 

Y este  es  un  ejemplo  de  su  forma  de  uso: 

{{ variable|cortar:"0" }} 

La  mayoria  de  los  filtros  no  reciben  argumentos.  En  este  caso,  basta  con  que  no 
incluyas  el  argumento  en  tu  funcion: 

# Unicamente  un  argumento. 

def  minusculas(valor): 

"Convierte  una  cadena  a minusculas" 

return  valor. lower() 

Una  vez  que  has  escrito  tu  definicion  de  filtro,  necesitas  registrarlo  en  una 
instancia  de  Library,  para  que  este  disponible  para  el  lenguaje  de  plantillas  de 
Django: 

register. filter(’cortar’,  cortar) 
register. filter(’minusculas’,  minusculas) 

El  metodo  Library. filter()  tiene  dos  argumentos: 

1.  El  nombre  del  filtro  (una  cadena) 

2.  La  funcion  filtro  propiamente  dicha 

Si  estas  usando  Python  2.7  o una  version  superior,  puedes  usar  register. filter() 
como  un  decorador: 

(©register.  filter(name- cortar’) 
def  cortar(valor,  arg): 

return  valor. replace(arg,  ) 

(©register. filter 
def  minusculas(valor): 
return  valor. lower() 

Si  no  provees  el  argumento  name,  como  en  el  segundo  ejemplo,  Django  usara  el 
nombre  de  la  funcion  como  nombre  del  filtro. 
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Veamos  entonces  el  ejemplo  completo  de  una  biblioteca  para  plantillas,  que 
provee  el  filtro  cortar: 

from  django  import  template 

register  = template.  Library() 

@register.filter(name- cortar’) 
def  cortar(valor,  arg): 

return  valor. replace(arg,  ”) 


Escribir  etiquetas  de  plantilla  personalizadas 


Las  etiquetas  son  mas  complejas  que  los  filtros  porque  las  etiquetas  pueden 
implementar  practicamente  cualquier  funcionalidad. 

El  capitulo  4 describe  como  el  sistema  de  plantillas  funciona  en  un  proceso  de  dos 
etapas:  compilacidn  y renderizado.  Para  delinir  una  etiqueta  de  plantilla 
personalizada,  necesitas  indicarle  a Django  como  manejar  ambas  etapas  cuando 
llega  a tu  etiqueta. 

Cuando  Django  compila  una  plantilla,  divide  el  texto  crudo  de  la  plantilla  en 
nodos.  Cada  nodo  es  una  instancia  de  django.template.Node  y tiene  un  metodo 
renderf).  Por  lo  tanto,  una  plantilla  compilada  es  simplemente  una  lista  de  objetos 
Node.  Por  ejemplo  considera  esta  plantilla: 

Hola,  {{  persona. nombre  }}. 

{%  ifequal  nombre. nacimiento  hoy  %} 
i Feliz  cumpleanos! 

{%  else  %} 

Vaya  de  seguro  recibiras  un  mensaje  de  cumpleanos 
sorpresa  esplendido  el  dla  de  tu  cumpleanos. 

{%  endifequal  %} 

En  un  formulario  compilado,  esta  plantilla  es  representada  como  una  lista  de 
nodos: 


■ Nodo  texto:  "Elola, " 

■ Nodo  variable:  person.nombre 

■ Nodo  texto:  ".\n\n" 

■ Nodo  IfEqual : nombre.nacimiento  y hoy 

Cuando  llamas  a render!)  en  una  plantilla  compilada,  la  plantilla  llama  a render!) 
en  cada  Node!)  de  su  lista  de  nodos,  con  el  contexto  proporcionado.  Los  resultados 
son  todos  concatenados  juntos  para  formar  la  salida  de  la  plantilla.  A si  que  para 
definir  una  etiqueta  de  plantilla  personalizada  debes  especificar  como  se  debe 
convertir  la  etiqueta  en  crudo  en  un  Node  (la  funcion  de  compilacidn)  y definir  lo  que 
hace  el  metodo  render!)  del  nodo. 

En  las  siguientes  secciones  explicaremos  los  pasos  necesarios  para  escribir  una 
etiqueta  propia. 
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Escribir  la  funcion  de  compilacion 

Para  cada  etiqueta  de  plantilla  que  encuentra,  el  interprete  ( parser)  de  plantillas 
llama  a una  funcion  de  Python  pasandole  el  contenido  de  la  etiqueta  y el  objeto 
parser  en  si  mismo.  Esta  funcion  tiene  la  responsabilidad  de  retornar  una  instancia 
de  Node  basada  en  el  contenido  de  la  etiqueta. 

Por  ejemplo,  escribamos  una  etiqueta  {%  current_time  %}  que  visualice  la 
fecha/hora  actuates  con  un  formato  determinado  por  un  parametro  pasado  a la 
etiqueta,  usando  la  sintaxis  de  strftime  (consulta 
http://www.djangoproject.eom/r/python/strftime/,  para  mas  detalles).  Es  una  buena 
idea  definir  la  sintaxis  de  la  etiqueta  previamente.  En  nuestro  caso,  supongamos  que 
la  etiqueta  debera  ser  usada  de  la  siguiente  manera: 

<p>La  fecha  actual  es  {%  fecha_actual  "%Y-%m-%d  %I:%M  %p"  %}.</p> 


Nota:  Si,  esta  etiqueta  de  plantilla  es  redundante  - La  etiqueta  {%  now  %}  incluida 
en  Django  por  defecto  hace  exactamente  lo  mismo  con  una  sintaxis  mas  simple.  Solo 
mostramos  esta  etiqueta  a modo  de  ejemplo. 


Para  evaluar  esta  funcion,  se  debera  obtener  el  parametro  y crear  el  objeto  Node: 
from  django  import  template 
register  = template.  Library() 

def  fecha_actual(parser,  token): 

try: 

# El  metodo  split_contents()  sabe  como  dividir  cadenas  entre  comillas. 

tag_nombre,  formato_cadena  = token. split_contents() 
except  ValueError: 

msg  = ’%r  la  etiqueta  requiere  un  simple  argumento’  % token. split_contents()[0] 

raise  template. TemplateSyntaxError(msg) 
return  NodoFechaActual(formato_cadena[l:-l]) 

Hay  muchas  cosas  en  juego  aqui: 

■ parser  e s la  instancia  del  parser.  No  lo  necesitamos  en  este  ejemplo. 

■ token. contents  es  un  cadena  con  los  contenidos  crudos  de  la  etiqueta,  en 
nuestro  ejemplo  seria:  ‘fecha_actual  “%Y-%m-%d  %I:%M  %p”’. 

■ El  metodo  token.split_contents()  separa  los  argumentos  en  sus  espacios, 
mientras  deja  unidas  a las  cadenas.  Evite  utilizar  token.contents.splitO  (el  cual 
usa  la  semantica  natural  de  Python  para  dividir  cadenas,  y por  esto  no  es  tan 
robusto,  ya  que  divide  en  todos  los  espacios,  incluyendo  aquellos  dentro  de 
cadenas  entre  comillas. 

■ Esta  funcion  es  la  responsable  de  generar  la  exception 
django.template.TemplateSyntaxError  con  mensajes  utiles,  ante  cualquier 
caso  de  error  de  sintaxis. 
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■ No  escribas  el  nombre  de  la  etiqueta  en  el  mensaje  de  error,  ya  que  eso 
acoplaria  innecesariamente  el  nombre  de  la  etiqueta  a la  funcion.  En  cambio, 
token. split_contents Q [0]  siempre  contendra  el  nombre  de  tu  etiqueta  - aun 
cuando  la  etiqueta  no  lleve  argumentos. 

■ La  funcion  devuelve  NodoFechaActual  (el  cual  mostraremos  en  un  momento) 
conteniendo  todo  lo  que  el  nodo  necesita  saber  sobre  esta  etiqueta.  En  este 
caso,  solo  pasa  el  argumento  "%Y-%m-%d  %I:%M  %p".  Las  comillas  son 
removidas  conformat_string[l:-l], 

■ Las  funciones  de  compilacion  de  etiquetas  de  plantilla  deben  devolver  una 
subclase  de  Node,  cualquier  otro  valor  es  un  error. 


Escribir  el  nodo  de  plantilla 

El  segundo  paso  para  escribir  etiquetas  propias,  es  definir  una  subclase  de  Node  que 
posea  un  metodo  render().  Continuando  con  el  ejemplo  previo,  debemos  definir 
CurrentTimeNode: 
import  datetime 

import  datetime 

class  NodoFechaActual(template.Node): 

def init (self,  formato_cadena): 

self.formato_cadena  = str(formato_cadena) 

def  render(self,  context): 

ahora  = datetime,  datetime.  now() 
return  ahora. strftime(self.formato_cadena) 

Estas  dos  funciones  ( init y render)  se  relacionan  directamente  con  los  dos 

pasos  para  el  proceso  de  la  plantilla  (compilacion  y renderizado).  La  funcion  de 
inicializacion  solo  necesitara  almacenar  el  string  con  el  formato  deseado,  el  trabajo 
real  sucede  dentro  de  la  funcion  render() 

Del  mismo  modo  que  los  filtros  de  plantilla,  estas  funciones  de  renderizacion 
deberian  fallar  silenciosamente  en  lugar  de  generar  errores.  En  el  unico  momento  en 
el  cual  se  le  es  permitido  a las  etiquetas  de  plantilla  generar  errores  es  en  tiempo  de 
compilacion. 

Registrar  la  etiqueta 

Finalmente,  deberas  registrar  la  etiqueta  con  tu  objeto  Library  dentro  del  modulo. 
Registrar  nuevas  etiquetas  es  muy  similar  a registrar  nuevos  filtros  (como  explicamos 
previamente).  Solo  deberas  instanciar  un  objeto  template. Library  y llamar  a su 
metodo  tag().  Por  ejemplo: 

re  g i ste  r . tag  ('f e c h a_actu  al ' , fe  c h a_actu  al ) 

El  metodo  tagO  toma  dos  argumentos: 

1.  El  nombre  de  la  etiqueta  de  plantilla  ( string) . Si  esto  se  omite,  se  utilizara  el 
nombre  de  la  funcion  de  compilacion. 


2.  La  funcion  de  compilacion. 
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De  manera  similar  a como  sucede  con  el  registro  de  filtros,  tambien  es  posible  utilizar 
register.tag  como  un  decorador  en  Python  2.7  o posterior: 


@register.tag(name="fecha_actual") 
def  fecha_actual(parser,  token): 

# ... 

@register.tag 

def  fecha_actual(parser,  token): 

# ... 

Si  omitimos  el  argumento  name,  asi  como  en  el  segundo  ejemplo,  Django  usara  el 
nombre  de  la  funcion  como  nombre  de  la  etiqueta. 

Definir  una  variable  en  el  contexto 

El  ejemplo  en  la  section  anterior  simplemente  devuelve  un  valor.  Muchas  veces  es 
util  definir  variables  de  plantilla  en  vez  de  simplemente  devolver  valores.  De  esta 
manera,  los  autores  de  plantillas  podran  directamente  utilizar  las  variables  que  esta 
etiqueta  defina. 

Para  definir  una  variable  en  el  contexto,  asignaremos  a nuestro  objeto  context 
disponible  en  el  metodo  renderf)  nuestras  variables,  como  si  de  un  diccionario  se 
tratase.  Aqui  mostramos  la  version  actualizada  de  NodoFechaActual  que  define  una 
variable  de  plantilla,  fecha_actual,  en  lugar  de  devolverla: 

class  NodoFechaActual2(template.Node): 

def init (self,  formato_cadena): 

self.formato_cadena  = str(formato_cadena) 

def  render(self,  context): 

ahora  = datetime. datetime. now() 

context['fecha_actual']  = ahora.strftime(self.formato_cadena) 
return  " 

Devolvemos  una  cadena  vacia,  debido  a que  renderf)  siempre  debe  devolver  un 
string.  Entonces,  si  todo  lo  que  la  etiqueta  hace  es  definir  una  variable,  renderf)  debe 
al  menos  devolver  una  cadena  vacia. 

De  esta  manera  usariamos  esta  nueva  version  de  nuestra  etiqueta: 

{%  fecha_actual2  "%Y-%M-%d  %I:%M  %p"  %} 

<p>Fecha:{{  fecha_actual  }}.</p> 

Pero  hay  un  problema  con  NodoFechaActual2:  el  nombre  de  la  variable 
fecha_actual  esta  definido  dentro  del  codigo.  Esto  significa  que  tendras  que  asegurar 
que  {{  fecha_actual }}  no  sea  utilizado  en  otro  lugar  dentro  de  la  plantilla,  ya  que  {% 
fecha_actual  %}  sobreescribira  el  valor  de  esa  otra  variable. 

Una  solution  mas  limpia,  es  recibiendo  el  nombre  de  la  variable  en  la  etiqueta  de 
plantilla  asi: 

{%  traer_fecha_actual  '%Y-%M-%d  %I:%M  %p"  as  mi_fecha_actual  %} 

<p>Fecha:  {{  mi_fecha_actual  }}.</p> 
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Para  hacer  esto,  necesitaremos  modificar  tanto  la  funcion  de  compilation  como  la 
clase  Node  de  la  siguiente  forma: 


template tags/etiquetas .py 


import  datetime 
import  re 

from  django  import  template 

register  = template.  Library() 

class  NodoFechaActual3(template.Node): 

def init (self,  formato_cadena,  var_nombre): 

self.formato_cadena  = str(formato_cadena) 
self.var_nombre  = var_nombre 

def  render(self,  context): 

ahora  = datetime,  datetime.  now() 

context[self.var_nombre]  = ahora.strftime(self.formato_cadena) 

return  ” 

@register.tag(name="traer_fecha_actual  ) 
def  traer_hora_actual(parser,  token): 

# Esta  version  usa  expresiones  regulares  para  analizar  el  contenido  de  la  etiqueta. 
try: 

# Dividir  por  None  ==  dividir  por  espacios. 

tag_nombre,  arg  = token. contents. split(  lo  , 1) 
except  ValueError: 

msg  = ’%r  La  etiqueta  requiere  un  simple  argumento’  % token. contents[0] 
raise  template. T emplateSyntaxError(msg) 

m = re.search(r’(.*?)  as  (\w+)’,  arg) 
if  m: 

fmt,  var_nombre  = m.groups() 

else: 

msg  = ’%r  Argumentos  no  validos  para  la  etiqueta’  % tag_nombre 
raise  template. T emplateSyntaxError(msg) 

if  not  (fmt[G]  ==  fmt[-l]  and  fmt[0]  in  ( )): 

msg  = "%r  Los  argumentos  deben  de  ir  entre  comillas"  % tag_nombre 
raise  template. TemplateSyntaxError(msg) 

return  NodoFechaActual3(fmt[l:-l],  var_nombre) 

Ahora,  traer_fecha_actual()  pasa  la  cadena  de  formato  junto  al  nombre  de  la 
variable  a NodoFechaActual3. 


Evaluar  hasta  otra  etiqueta  de  bloque 

Las  etiquetas  de  plantilla  pueden  funcionar  como  bloques  que  contienen  otras 
etiquetas  (piensa  en  {%  if  %},  {%  for  %},  etc.).  Para  crear  una  etiqueta  como  esta,  usa 
parser.parseO  en  tu  funcion  de  compilation. 

Aqui  vemos  como  esta  implementada  una  etiqueta  {%  coment  %}: 
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def  do_comment(parser,  token): 

nodelist  = parser.  parse((’endcomment’,)) 
parser. delete_first_token() 
return  CommentNodeQ 

class  CommentNode(template.Node): 
def  render(self,  context): 
return  ” 

parser.parseO  toma  una  tupla  de  nombres  de  etiquetas  de  bloque  para  evaluar  y 
devuelve  una  instancia  de  django. template. NodeList,  la  cual  es  una  lista  de  todos  los 
objetos  Nodo  que  el  parser  encontro  antes  de  haber  encontrado  alguna  de  las 
etiquetas  nombradas  en  la  tupla. 

Entonces,  en  el  ejemplo  previo,  nodelist  es  una  lista  con  todos  los  nodos  entre 
{%  comment  %}  y {%  endcomment  %},  excluyendo  a los  mismos  {%  comment  %}  y {% 
endcomment  %}. 

Luego  de  que  parser.parseO  es  llamado  el  parser  aun  no  ha  “consumido”  la 
etiqueta  {%  endcomment  %},  es  por  eso  que  en  el  codigo  se  necesita  llamar 
explicitamente  a parser.delete_first_token()  para  prevenir  que  esta  etiqueta  sea 
procesada  nuevamente. 

Luego,  CommentNode.renderO  simplemente  devuelve  un  siring  vacio.  Cualquier 
cosa  entre  {%  comment  %}  y {%  endcomment  %}  es  ignorada. 


Evaluar  hasta  otra  etiqueta  de  bloque  y guardar  el  contenido 

En  el  ejemplo  anterior,  do_comment()  desecho  todo  entre  {%  comment  %}  y 

{%  endcomment  %},  pero  tambien  es  posible  hacer  algo  con  el  codigo  entre  estas 

etiquetas. 

Por  ejemplo,  presentamos  una  etiqueta  de  plantilla,  {%  upper  %},  que  convertira  a 
mayusculas  todo  hasta  la  etiqueta  {%  endupper  %}: 

{%  upper  %} 

Esto  aparecera  en  mayusculas,  {{tu_nombre  }}. 

{%  endupper  %} 

Como  en  el  ejemplo  previo,  utilizaremos  parser.parseO  pero  esta  vez  pasamos  el 
resultado  de  nodelist  a Node  asi: 

(©register. tag 

def  do_upper(parser,  token): 

nodelist  = parser. parse((’endupper’,)) 
parser. delete_first_token() 
return  UpperNode(nodelist) 

class  UpperNode(template.Node): 

def init (self,  nodelist): 

self.nodelist  = nodelist 

def  render(self,  context): 

output  = self. nodelist. render(context) 
return  output. upperQ 
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El  unico  concepto  nuevo  aqui  es  self.nodelist.render(context)  en 
UpperNode.render().  El  mismo  simplemente  llama  a renderO  en  cada  Node  en  la  lista 
de  nodos. 

Para  mas  ejemplos  de  renderizado  complejos,  examina  el  codigo  fuente  para  las 
etiquetas  {%  if  %},  {%  for  %},  {%  ifequal  %}  y {%  ifchanged  %}.  Puedes  encontrarlas  en 
el  directorio  django/template/defaulttags.py. 


Un  atajo  para  etiquetas  simples 

Muchas  etiquetas  de  plantilla  reciben  un  unico  argumento-una  cadena  o una 
referencia  a una  variable  de  plantilla  y retornan  una  cadena  luego  de  hacer  algun 
procesamiento  basado  solamente  en  el  argumento  de  entrada  e information  externa. 
Por  ejemplo  la  etiqueta  fecha_actual  que  escribimos  antes  es  de  este  tipo.  Le  pasamos 
una  cadena  de  formato,  y retorna  la  hora  como  una  cadena. 

Para  facilitar  la  creation  de  esos  tipos  de  etiquetas,  Django  provee  una  funcion 
auxiliar:  simple_tag.  Esta  funcion,  que  es  un  metodo  de  django.template.Library, 
recibe  una  funcion  que  acepta  un  argumento,  lo  encapsula  en  una  funcion  render  y el 
resto  de  las  piezas  necesarias  que  mencionamos  previamente  y lo  registra  con  el 
sistema  de  plantillas. 

Nuestra  funcion  fecha_actual  podria  entonces  ser  escrita  de  la  siguiente  manera: 

def  fecha_actual(format_string): 

return  datetime. datetime. now().strftime(format_string) 

register. simple_tag(fecha_actual) 

Y la  podemos  registrar  mediante  un  decorador  asi: 

(©register.  simple_tag 
def  fecha_actual(token): 


Un  par  de  cosas  a tener  en  cuenta  acerca  de  la  funcion  auxiliar  simple_tag: 

■ Solo  se  pasa  un  argumento  a nuestra  funcion. 

■ La  verification  de  la  cantidad  requerida  de  argumentos  ya  ha  sido  realizada 
para  el  momento  en  el  que  nuestra  funcion  es  llamada,  de  manera  que  no  es 
necesario  que  lo  hagamos  nosotros. 

■ Las  comillas  alrededor  del  argumento  (si  existieran)  ya  han  sido  quitadas,  de 
manera  que  recibimos  una  cadena  comun. 


Etiquetas  de  inclusion 

Otro  tipo  de  etiquetas  de  plantilla  comun  es  aquel  que  visualiza  ciertos  datos 
renderizando  otra  plantilla.  Por  ejemplo  la  interfaz  de  administration  de  Django  usa 
etiquetas  de  plantillas  personalizadas  ( custom ) para  visualizar  los  botones  en  la  parte 
inferior  de  la  paginas  de  formularios  “agregar/cambiar”.  Dichos  botones  siempre  se 
ven  igual,  pero  el  destino  del  enlace  cambia  dependiendo  del  objeto  que  se  esta 
modificando.  Se  trata  de  un  caso  perfecto  para  el  uso  de  una  pequena  plantilla  que  es 
llenada  con  detalles  del  objeto  actual. 
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Ese  tipo  de  etiquetas  reciben  el  nombre  de  etiquetas  de  inclusion.  Es 
probablemente  mejor  demostrar  como  escribir  una  usando  un  ejemplo.  Escribamos 
una  etiqueta  que  produzca  una  lista  de  libros  para  un  simple  objeto  Libro.  Usaremos 
una  etiqueta  como  esta: 

{%  libros_por_autor  autor  %} 

El  resultado  sera  algo  como  esto: 

<ul> 

<li>Libro  uno</li> 

<li>Libro  dos</li> 

<li>Otro  libro</li> 

</ul> 

Primero  definimos  la  funcion  que  toma  un  argumento  y produce  un  diccionario  de 
datos  con  los  resultados.  Nota  que  nos  basta  un  diccionario  y no  necesitamos 
retornar  nada  mas  complejo. 

Esto  sera  usado  como  el  contexto  para  el  fragmento  de  plantilla: 

def  libros_por_autor(autor): 

libros  = Libro. objects. filter(autores id=autor.id) 

return  {’libros’:  libros} 

Luego  creamos  la  plantilla  usada  para  renderizar  la  salida  de  la  etiqueta: 

<ul> 

{%  for  libro  in  libros  %} 

<li>{{  libro. titulo  }}</li> 

{%  endfor  %} 

</ul> 

Finalmente  una  vez  que  la  hemos  creado,  es  necesario  registrar  la  etiqueta  de 
inclusion  invocando  al  metodo  inclusion_tag()  sobre  un  objeto  Library. 

Continuando  con  nuestro  ejemplo,  si  la  plantilla  se  encuentra  en  un  archivo 
llamado  libros_por_autor.html,  registraremos  la  plantilla  de  la  siguiente  manera: 
register.inclusion_tag('libros_por_autor.htmr)(libros_por_autor) 

Como  siempre,  la  sintaxis  de  decoradores  de  Python  tambien  funciona,  de  manera 
que  podemos  haber  escrito: 

@register.inclusion_tag('libros_por_autor.htmr) 
def  libros_por_autor  (autor) : 

# ... 

A veces  tus  etiquetas  de  inclusion  necesitan  tener  acceso  a valores  del  contexto  de 
la  plantilla  padre.  Para  resolver  esto  Django  provee  una  option  takes_context  para  las 
etiquetas  de  inclusion.  Si  especificas  takes_context  cuando  creas  una  etiqueta  de 
plantilla,  la  misma  no  tendra  argumentos  obligatorios  y la  funcion  Python 
subyacente  tendra  un  argumento:  el  contexto  de  la  plantilla  en  el  estado  en  el  que  se 
encontraba  cuando  la  etiqueta  fue  invocada. 

Por  ejemplo  supongamos  que  estas  escribiendo  una  etiqueta  de  inclusion  que  sera 
siempre  usada  en  un  contexto  que  contiene  variables  homejink  y home_title  que 
apuntan  a la  pagina  principal. 

As!  es  como  se  verfa  la  funcion  Python: 
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@register.inclusion_tag(’link.html’,  takes_context=True) 
def  jumpjink(context): 
return  { 

’link’:  context[’home_link’], 

’title’:  context[’home_title’], 

} 


Nota:  El  primer  parametro  de  la  funcion  Gfafrellamarse  context. 


La  plantilla  link.html  podna  contener  lo  siguiente: 

Ir  directamente  a <a  href="{{  link  }}">{{  title  }}</a>. 

Entonces,  cada  vez  que  desees  usar  esa  etiqueta  personalizada,  carga  su  biblioteca 
y ejecutala  sin  argumentos,  de  la  siguiente  manera: 

{%  jumpjink  %} 


Escribir  cargadores  de  plantillas  personalizados 

Los  cargadores  de  plantillas  incluidos  con  Django  (descritos  en  la  section  “Etiquetas 
de  inclusion”  mas  arriba)  cubriran  usualmente  todas  tus  necesidades  de  carga  de 
plantillas,  pero  es  muy  sencillo  escribir  el  tuyo  propio  si  necesitas  alguna  logica 
especial  en  dicha  carga.  Por  ejemplo  podrfas  cargar  plantillas  desde  una  base  de 
datos,  o directamente  desde  un  repositorio  Subversion  usando  las  librerias  ( bindings ) 
Python  de  Subversion,  o (como  veremos)  desde  un  archivo  ZIP. 

Un  cargador  de  plantillas  -esto  es,  cada  entrada  en  la  variables  de  configuracion 
TEMPLATE_LOADERS-  debe  ser  un  objeto  invocable  [callable)  con  la  siguiente 
interfaz:  load_template_source(template_nombre,  template_dirs=None) 

El  argumento  template_nombre  es  el  nombre  de  la  plantilla  a cargar  (tal  como  fue 
pasado  a loader. get_template()  o loader.select_template())  y template_dirs  es  una 
lista  opcional  de  directorios  en  los  que  se  buscara  en  lugar  de  TEMPLATE_DIRS. 

Si  un  cargador  es  capaz  de  cargar  en  forma  exitosa  una  plantilla,  debe  retornar  una 
tupla:  (template_source,  template_path).  Donde  template_source  es  la  cadena  de 
plantilla  que  sera  compilada  por  la  maquinaria  de  plantillas,  y template_path  es  la 
ruta  desde  la  cual  fue  cargada  la  plantilla.  Dicha  ruta  podria  ser  presentada  al  usuario 
para  fines  de  depuration  asi  que  debe  identificar  en  forma  rapida  desde  donde  fue 
cargada  la  plantilla. 

Si  al  cargador  no  le  es  posible  cargar  una  plantilla,  debe  lanzar 
django.template.TemplateDoesNotExist. 

Cada  funcion  del  cargador  debe  tambien  poseer  un  atributo  de  funcion  is_usable. 
Este  es  un  Booleano  que  le  informa  a la  maquinaria  de  plantillas  si  este  cargador  esta 
disponible  en  la  instalacion  de  Python  actual.  Por  ejemplo  el  cargador  desde  eggs 
(que  es  capaz  de  cargar  plantillas  desde  eggs  Python)  fija  is_usable  a False  si  el 
modulo  pkg_resources  no  se  encuentra  instalado,  porque  pkg_resources  es  necesario 
para  leer  datos  desde  eggs. 

Un  ejemplo  ayudara  a clarificar  todo  esto.  Aqui  tenemos  una  funcion  cargadora  de 
plantillas  que  puede  cargar  plantillas  desde  un  archivo  ZIP.  Usa  una  variable  de 
configuracion  personalizada  TEMPLATE_ZIP_FILES  como  una  ruta  de  busqueda  en 
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lugar  de  TEMPLATE_DIRS  y espera  que  cada  item  en  dicha  ruta  sea  un  archivo  ZIP 
que  contiene  plantillas: 

import  zipfile 

from  django.conf  import  settings 

from  django. template  import  TemplateDoesNotExist 

def  load_template_source(template_nombre,  template_dirs=  ■lone): 

Cargador  de  plantillas  desde  archivos  ZIP. 

template_zipfiles  = getattr(settings,  "TEMPLATE_ZIP_FILES",  []) 

# Carga  cada  archivo  ZIP  de  TEMPLATE_ZIP_FILES. 

for  fnombre  in  template_zipfiles: 

try: 

z = zipfile.  ZipFile(fnombre) 
source  = z.read(template_nombre) 
except  (lOError,  KeyError): 

continue 

z.close() 

# Encuentra  las  plantillas  y retorna  el  codigo. 

template_path  = "%s:%s"  % (fnombre,  template_nombre) 
return  (source,  template_path) 

# Si  en  este  punto  la  plantilla  no  ha  sido  cargada,  lanzamos  un  error. 

raise  TemplateDoesNotExist(template_nombre) 

# Este  cargador  siempre  es  usable  (ya  que  zipfile  esta  incluido  en  Python) 

load_template_source.is_usable  = 

El  unico  paso  restante  si  deseamos  usar  este  cargador  es  agregarlo  a la  variable  de 
configuration  TEMPLATE_LOADERS.  Si  pusieramos  este  codigo  en  un  paquete 
llamado  misitio. zip_ loader e n to n c e s agregariamos 
misitio.zip_loader.load_  template_source  a TEMPLATE_LOADERS. 


Usar  la  referenda  de  plantillas  incorporadas 

La  interfaz  de  administracion  de  Django  incluye  una  referencia  completa  de  todas  las 
etiquetas  y filtros  de  plantillas  disponibles  para  un  sitio  determinado.  Esta  designada 
para  ser  una  herramienta  que  los  programadores  Django  proveen  a los 
desarrolladores  de  plantillas.  Para  activarla  sigue  los  siguientes  pasos: 

■ Agrega  la  aplicacion  'django. contrib.admindocs'  al  archivo  settings.py  en  la 
variable  INSTALLED_APPS  (como  lo  harias  con  cualquier  otra  aplicacion). 

■ Agrega  el  patron,  (r'Aadmin/doc/\  include('django.contrib.admindocs.urls')) 
al  archivo  urls.py,  solo  asegurate  que  aparezca  antes  que  el  patron  que  apunta 
a la  interfaz  administrativa  (r'Aadmin/') 

■ Dirige  tu  navegador  a:  / admin/ doc/. 

Si  entras  a la  interfaz  de  administracion,  da  clic  en  el  nuevo  enlace  Documentation 
en  la  zona  superior  derecha  de  la  pagina. 

La  referencia  esta  dividida  en  cuatro  secciones:  etiquetas,  filtros,  modelos  y vistas. 
Las  secciones  eliquelas  y filtros  describen  todas  las  etiquetas  incluidas  (en  efecto,  las 
referencias  de  etiquetas  y filtros  del  capitulo  4 han  sido  extraidas  directamente  de 
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esas  paginas)  asi  como  cualquier  biblioteca  de  etiquetas  o filtros  personalizados 
disponible. 


^ ^ localhostSOOO/admin/doc/ 

▼ e|  ☆ £ S\  + * = 

Django  administration 

Welcome,  saul.  View  site  / Documentation  / Change  password  / Log  out 

Home  > Documentation 

Documentation 


Tags 

List  of  all  the  template  tags  and  their  functions. 

Filters 

Filters  are  actions  which  can  be  applied  to  variables  in  a template  to  alter  the  output. 

Models 

Models  are  descriptions  of  all  the  objects  in  the  system  and  their  associated  fields.  Each  model  has  a list  of  fields  which  can  be  accessed  as  template  variables. 
Views 

Each  page  on  the  public  site  is  generated  by  a view.  The  view  defines  which  template  is  used  to  generate  the  page  and  which  objects  are  available  to  that  template. 
Bookmarklets 

Tools  for  your  browser  to  quickly  access  admin  functionality. 


Imagen  9.1  El  framework  de  documentation  de  Django 

La  pagina  views  es  la  mas  valiosa.  Cada  URL  en  tu  sitio  tiene  alii  una  entrada 
separada.  Si  la  vista  relacionada  incluye  una  cadena  de  documentacion  o docstring, 
haciendo  clic  en  la  URL  te  mostrara  lo  siguiente: 

■ El  nombre  de  la  funcion  de  vista  que  genera  esa  vista. 

■ Una  breve  descripcion  de  lo  que  hace  la  vista. 

■ El  contexto,  o una  lista  de  variables  disponibles  en  la  plantilla  de  la  vista. 

■ El  nombre  de  la  plantilla  o plantillas  usados  para  esa  vista. 

Para  un  ejemplo  detallado  de  la  documentacion  de  vistas,  lee  el  codigo  fuente  de  la 
vista  generica  de  Django  objectjist  la  cual  se  encuentra  en 
django /views  / generic /list_detail.py. 

Debido  a que  los  sitios  implementados  con  Django  generalmente  usan  objetos  de 
bases  de  datos,  las  paginas  models  describen  cada  tipo  de  objeto  en  el  sistema  asi 
como  todos  los  campos  disponibles  en  esos  objetos. 

En  forma  conjunta,  las  paginas  de  documentacion  deberian  proveerte  cada 
etiqueta,  filtro,  variable  y objeto  disponible  para  su  uso  en  una  plantilla  arbitraria. 

Configurando  el  sistema  de  plantillas  en  modo 

autonomo 


Nota:  Estas  seccion  es  solo  de  interes  para  aquellos  que  intentan  usar  el  sistema 
de  plantillas  como  un  componente  de  salida  en  otra  aplicacion.  Si  estas  usando  el 
sistema  como  parte  de  una  aplicacion  Django,  la  informacion  aqui  presentada  no  es 
relevante  para  ti. 


Normalmente  Django  carga  toda  la  informacion  de  configuracion  que  necesita 
desde  su  propio  archivo  de  configuracion  por  omision,  combinado  con  las  variables 
de  configuracion  en  el  modulo  indicado  en  la  variable  de  entorno 
DJANGO_SETTINGS_MODULE.  Pero  si  estas  usando  el  sistema  de  plantillas 
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independientemente  del  resto  de  Django,  el  esquema  de  la  variable  de  entorno  no  es 
muy  conveniente  porque  probablemente  quieras  configurar  el  sistema  de  plantillas 
en  una  manera  mas  acorde  con  el  resto  de  tu  aplicacion  en  lugar  de  tener  que  vertelas 
con  archivos  de  configuracion  e indicando  los  mismos  con  variables  de  entorno. 

Para  resolver  este  problema  necesitas  usar  la  option  de  configuracion  manual 
descrita  en  forma  completa  en  el  Apendice  E.  En  resumen,  necesitas  importar  las 
partes  apropiadas  del  sistema  de  plantillas  y entonces,  antes  de  invocar  alguna  de  las 
funciones  de  plantillas,  invoca  a django.conf.settings. configure!)  con  cualquier  valor 
de  configuracion  que  desees  especificar. 

Podrias  desear  considerar  fijar  al  menos  TEMPLATE_DIRS  (si  vas  a usar  cargadores 
de  plantillas),  DEFAULT_CE1ARSET  (aunque  el  valor  por  omision  utf-8 
probablemente  sea  adecuado)  y TEMPLATE_DEBUG.  Todas  las  variables  de 
configuracion  estan  descritas  en  el  Apendice  E y todas  las  variables  cuyos  nombres 
comienzan  con  TEMPLATE  son  de  obvio  interes. 

<?,Que  sigue? 

Continuamos  esta  section  con  temas  avanzados,  el  siguiente  capitulo  trata  sobre  el 
uso  avanzado  de  los  modelos  en  Django. 


CAPITULO  10 


Modelos  avanzados 


En  el  capitulo  5,  presentamos  una  pequena  introduccion  a la  capa  de  base  de  datos 
- la  cual  define  los  modelos  de  la  base  de  datos  y la  forma  de  usar  la  API  para  crear, 
recuperar,  actualizar  y borrar  registros.  En  este  capitulo,  nos  adentraremos  un  poco 
mas,  en  las  caracterlsticas  avanzadas  de  la  capa  de  modelos  de  Django. 

Relaciones  entre  objetos 

Recuerdas  el  modelo  que  creamos  en  el  capitulo  5: 


libros/models . py 


from  django.db  import  models 

class  Editor(models. Model): 

nombre  = models.  CharField(max_length=30) 
direccion  = models.  CharField(max_length=5) 
ciudad  = models.  CharField(max_length=60) 
estado  = models.  CharField(max_length= 30) 
pais  = models.  CharField(max_length=30) 
website  = models. URLFieldQ 

class  Meta: 

ordering  = ['nombre"] 
verbose_name_plural  = "Editores" 

def str (self):  # Unicode en  Python  2 

return  self.nombre 

class  Autor(models. Model): 

nombre  = models.  CharField(max_length=30) 
apellidos  = models.  CharField(max_length=40) 
email  = models. EmailField('e-mair,  blank=True) 

def str (self):  # Unicode en  Python  2 

return  '%s  %s'  % ( df. nombre,  apellidos) 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 
editor  = models. ForeignKey(Editor) 

fecha_publicacion  = models. DateField(blank=True,  null=True) 
portada  = models. lmageField(upload_to='portadas') 

class  Meta: 

ordering  = ["nombre"] 


203 


CAPITULO  1 0 MODELOS  AVANZADOS 


verbose_name_plural  = "Autores" 

def str (self):  # Unicode en  Python  2 

return  self.titulo 


Como  explicamos  en  el  capltulo  5,  para  acceder  directamente  al  valor  de  un 
determinado  campo  en  la  base  de  datos,  es  necesario  usar  los  atributos  del  objeto. 
Por  ejemplo,  para  determinar  el  titulo  de  un  libro  con  un  ID  5 (ID:  El  identificador  o 
clave  primaria,  siempre  que  esta  exista),  hacemos  lo  siguiente: 

>»  from  biblioteca.models  import  Libro 
»>  b = Libro. objects. get(id=5) 

»>  b. titulo 

The  definitive  guide' 

Pero  una  cosa  que  no  mencionamos  previamente,  fueron  las  relaciones  entre 
objetos  - Nos  referimos  a los  campos  expresados  como  ForeignKey  o 
ManyToManyField,  los  cuales  actuan  de  modo  ligeramente  diferente. 


Accediendo  a valores  en  claves  foraneas 

Cuando  accedes  a un  campo  del  tipo  ForeignKey  (Relacion  foranea,  del  tipo  muchos 
auno) 

Puedes  obtener  el  modelo  del  objeto  relacionado,  de  la  siguiente  forma: 

»>  from  biblioteca.models  import  Editor,  Libro 
»>  b = Libro. objects. get(  =5) 

»>  b. editor 

<Publisher:  Apress  Publishing> 

»>  b. editor. website 
u'http://www.apress.com/' 

Como  habras  notado,  la  forma  en  que  trabajan  los  campos  ForeignKey,  es 
ligeramente  diferente,  debido  a la  naturaleza  poco  simetrica  de  la  relacion.  Por 
ejemplo  para  conseguir  una  lista  de  libros  de  un  editor  en  especifico,  usa 
editores.libro_set.all(),  asi: 

»>  p = Editor. objects. get(nombre='Apress  Publishing') 

»>  p.libro_set.all() 

[<Libro:  The  Django  Libro>,  <Libro:  Dive  Into  Python>,  ...] 

Detras  de  escena,  libro_set  es  solo  un  QuerySet  (el  cual  cubrimos  en  el  Capitulo5)  y 
puede  ser  filtrado  y rebanado,  tal  como  cualquier  otro  QuerySet.  Por  ejemplo: 

»>  p = Editor. objects. get(nombre='Apress  Publishing') 

»>  p.libro_set.filter(titulo icontains-django) 

[<Libro:  The  definitive  guide>,  <Libro:  Pro  Django>] 

El  nombre  del  atributo  libro set  es  generado  agregando  el  nombre  del  modelo  en 

minusculas  a _set. 
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Accediendo  a valores  en  claves  muchos  a muchos 

Los  valores  muchos  a muchos  (Many-to-many)  trabajan  de  forma  parecida  a los 
valores  en  campos  foraneos,  a menos  que  tratemos  con  valores  QuerySet  en  lugar  de 
instancias  del  modelo.  Por  ejemplo,  este  es  la  forma  que  se  muestran  los  autores  de 
un  libro: 

»>  b = Libro. objects. get( ' =5) 

»>  b. autores. all() 

[<Author:  Adrian  Holovaty>,  <Author:  Jacob  Kaplan-Moss>] 

»>  b. autores. filter(nombre- Adrian') 

[<Author:  Adrian  Holovaty>] 

»>  b. autores. filter(nombre- Adam') 

D 


Esto  tambien  trabaja  en  orden  inverso,  Para  visualizar  todos  los  libros  de  un 
determinado  autor,  usa  autor.libro_set,  asi: 

»>  from  biblioteca.models  import  Autor 

»>  a = Autor. objects. get(nombre='Adrian',  apellidos='Holovaty') 

»>  a.libro_set.all() 

[<Libro:  The  Django  Libro>,  <Libro:  Adrian's  Other  Libro>] 

A1  igual  que  con  lo  campos  ioraneos,  el  no  mb  re  del  atributo  libro_setes  generado 
agregando  el  nombre  del  modelo  en  minusculas  a _set. 


Como  realizar  cambios  al  esquema  de  la  base  de 

datos 

Cuando  introducimos  el  comando  migrate  en  el  capitulo  5,  hicimos  enfasis  en  que  el 
comando  migrate  crea  las  tablas  que  no  existen  en  la  base  de  datos,  sincronizando  los 
modelos  - pero  nos  falto  comentar  que  no  solo  crea  modelos,  tambien  agrega  y 
renombra  campos,  elimina  y agrega  modelos,  por  lo  que  en  la  mayoria  de  casos  no 
necesitaras  hacer  estos  cambios  manualmente. 

Esta  section  explica  como  hacer  cambios  al  esquema  de  la  base  de  datos,  usando 
los  comandos  migrate  y makemigrations. 

Cuando  se  trata  con  cambios  al  esquema  de  la  base  de  datos,  es  importante  tener 
en  cuenta  algunas  cuestiones  relacionadas  con  la  forma  en  que  trabaja  la  capa  de 
base  de  datos  de  Django: 

■ Django  se  quejara  estrepitosamente  si  un  modelo  contiene  un  campo  que 
todavia  no  se  ha  creado  en  la  tabla  de  base  de  datos.  Esto  causara  un  error  la 
primera  vez  que  utilices  la  API  de  la  base  de  datos  (es  decir,  esto  sucede  en 
tiempos  de  ejecucion  del  codigo,  no  en  tiempos  de  compilation). 

■ A Django  no  le  importa  si  una  tabla  de  la  base  de  datos,  contiene  columnas 
que  no  estan  definidas  en  el  modelo. 

■ A Django  no  le  importa  si  una  base  de  datos  contiene  una  tabla  que  no  esta 
representada  por  un  modelo. 

Por  lo  que  realizar  cambios  al  esquema,  solo  es  cuestion  de  cambiar  varias  piezas  - 
el  codigo  Python  y la  base  de  datos  en  si  mismo  en  el  orden  correcto. 
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Migraciones 

Los  dos  comandos  que  se  encargan  de  interactuar  con  las  migraciones  y manejar  el 
esquema  de  la  base  de  datos  en  Django  son: 


makemigrations: 

Comando  responsable  de  crear  nuevas  migraciones 
basadas  en  los  cambios  hechos  a los  modelos. 

migrate: 

Comando  responsable  de  aplicar  las  migraciones  y 
sincronizar  los  modelos  de  la  base  de  datos  y listar  su 
estatus. 

Las  migraciones  son  la  forma  en  que  Django  propaga  los  cambios  que  realizas  a tus 
modelos  (agregando  campos,  eliminando  un  modelo,  etc.)  en  el  esquema  de  la  base 
de  datos.  Se  disenan  para  ser  sobre  todo  automaticas,  pero  necesitas  tener  cuidado 
con  los  problemas  comunes  que  puedan  surgir,  ya  que  un  error  puede  dejar 
inutilizable  tu  base  de  datos. 

Un  poco  de  historia 

Antes  de  la  version  1.7  de  Django,  solo  era  posible  agregar  modelos  nuevos  a la  base 
de  datos;  no  era  posible  alterar  o quitar  los  modelos  existentes,  usando  el  comando 
syncdb  (el  precursor  de  migrate).  Por  lo  que  si  se  agregaba  y cambiaba  un  campo  de 
un  modelo,  o si  se  eliminaba  un  modelo,  era  necesario  realizar  el  cambio  en  la  base 
de  datos  manualmente  usando  SQL. 

Por  lo  que  surgieron  algunas  herramientas  de  terceros  en  especial  South  que 
proveian  soporte  para  realizar  estos  cambios  adicionales  en  el  esquema  de  la  base  de 
datos,  con  el  tiempo  este  tipo  de  soporte  fue  considerado,  lo  suficientemente 
importante  que  fue  incluido  en  el  codigo  base  de  Django. 

El  sistema  de  migraciones  de  Django,  se  divide  en  dos  partes:  la  logica  que  calcula 
y almacena  las  operaciones  que  se  ejecutan  (django.db. migrations),  y la  capa  de 
abstraction  de  la  base  de  datos  que  se  encarga  de  cosas  como  “crear  un  modelo” 
“borrar  un  campo”  en  SQL  -el  cual  es  trabajo  del  editor  de  esquema  (SchemaEditor). 

Trabajar  con  migraciones  es  sencillo,  cambia  tu  modelo  - es  decir  agrega  un 
campo  y/o  remueve  un  modelo...  - y ejecuta  los  comandos  makemigrations  y 
migrate  en  ese  orden. 

Agregar  campos 

Cuando  se  agrega  un  campo  a una  tabla/modelo  en  un  entorno  en  produccion,  el 
truco  es  realizarlo  primero  en  un  servidor  de  desarrollo  y luego  llevar  los  cambios  al 
sitio  de  produccion. 

Sin  embargo  las  migraciones  funcionaran  de  la  misma  manera  en  el  mismo 
conjunto  de  datos  y produciran  resultados  constantes,  lo  que  significa  que  pueden 
ser  usadas  en  desarrollo  y en  produccion  bajo  las  mismas  condiciones  y 
circunstancias  y con  los  mismos  resultados. 

Para  agregar  campos  a un  modelo  sigue  estos  pasos: 

1.  Agrega  el  campo  a tu  modelo. 

2.  Asegurate  que  el  campo  incluya  las  opciones  blank=True  o null=True  (si  es  un 
campo  basado  en  fechas  o numerico). 

3.  Ejecuta  el  comando  manage.py  makemigrations,  para  grabar  los  cambios. 

4.  Sincroniza  los  modelos  con  manage.py  migrate. 
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5.  Ejecuta  manage.py  shell  y verifica  que  el  nuevo  campo  se  haya  agregado 
correctamente,  importa  el  modelo  y realiza  una  consulta  a la  base  de  datos 
(por  ejemplo  con  Libro. objects. all()[:5]).  Si  la  actualization  fue  correcta,  la 
declaracion  anterior  debe  trabajar  sin  errores. 

Como  ejemplo,  examinemos  los  pasos  necesarios  para  agregar  un  campo 
num_paginas  al  modelo  Libro  del  capltulo  5. 

Lo  primero  que  haremos  sera  cambiar  el  modelo  y agregarle  el  nuevo  campo  asi: 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 
editor  = models. ForeignKey(Editor) 

fecha_publicacion  = models. DateField(blank=True,  null=True) 
portada  = models.  lmageField(upload_to='portadas') 

num  paginas  = models. lntegerField(blank=  rue,  null=  True) 


Nota:  Lee  la  section  “Crear  campos  opcionales”  del  capltulo  6,  para  conocer  los 
detalles  importantes  acerca  del  porque  incluimos  blank=True  y null=True. 


Una  vez  que  hemos  cambiado  nuestro  modelo,  podemos  validarlo  usando  el 
comando  python  manage.py  check,  para  asegurarnos  de  que  todo  esta  correctamente 
en  su  lugar,  si  el  comando  no  lanza  ningun  error,  podemos  crear  las  migraciones  con 
el  comando  python  manage.py  makemigrations,  con  el  que  obtendremos  una  salida 
como  esta: 

Migrations  for  ' biblioteca 1 : 

0002_auto_20150216_1318 . py : 

-Add  field  num_paginas  to  libro 

Tus  modelos  seran  explorados  y comparados  con  las  versiones  contenidas  en  el 
fichero  actual  de  migraciones,  y entonces  un  nuevo  conjunto  de  migraciones  sera 
escrito.  Asegurate  de  leer  la  salida  para  ver  lo  que  el  comando  makemigrations  piensa 
que  ha  cambiado  - no  es  perfecto,  sobre  todo  en  cambios  complejos,  puede  ser  que 
no  detecte  lo  que  esperabas. 

Ahora  podemos  ejecutar  el  comando  python  manage.py  sqlmigrate  biblioteca  para 
ver  la  declaracion  CREATE  TABLE  de  SQL.  Dependiendo  de  la  base  de  datos  la  salida 
puede  variar: 

BEGIN; 

CREATE  TABLE  "biblioteca_libro_new"  ( 

"id"  serial  NOT  NULL  PRIMARY  KEY, 

"titulo"  varchar(lOO)  NOT  NULL, 

"editoresjd"  integer  NOT  NULL  REFERENCES  "libros_editores"  ("id"), 
"fecha_publicacion"  date  NOT  NULL, 

"num^paginas"  integer  NULL 

#... 

); 


La  nueva  columna  es  representada  en  SQL  asi: 
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"num_pages"  integer  NULL 


POR  QUE  AGREGAMOS  COLUMNAS  NOT  NULL? 


En  este  punto  vale  la  pena  hacer  mention  de  una  delicada  sutileza,  cuando 
agregamos  el  campo  num_paginas  al  modelo,  incluimos  las  opciones  blank=True  y 
null=True  ya  que  una  columna  de  una  base  de  datos,  debe  de  contener  valores  NULL 
cuando  es  creada  por  primera  vez. 

Sin  embargo  tambien  es  posible  agregar  columnas  que  no  contengan  valores 
NULL.  Para  ello  es  necesario  crear  las  columnas  como  NULL  y luego  agregar  valores 
por  defecto  y despues  alterar  la  columna  para  modificarla  a NOT  NULL. 

Usando  SQL  tendriamos  que  hacer  esto: 

BEGIN; 

ALTER  TABLE  libros_libro  ADD  COLUMN  num_paginas  integer; 

UPDATE  libros_libro  SET  num_pages=0; 

ALTER  TABLE  librosjibro  ALTER  COLUMN  num_paginas  SET  NOT  NULL; 

COMMIT; 

Afortunadamente  el  comando  migrate  se  encarga  de  realizar  este  trabajo  por  ti,  ya 
que  detecta  cuando  se  quiera  agregar  un  campo  que  contiene  valores  NOT  NULL, 
advirtiendonos  que  tratamos  de  agregar  un  campo  NOT  NULL  y que  no  se  puede 
hacer  eso  (ya  que  la  base  de  datos  necesita  rellenar  las  filas  existentes.) 

Por  lo  que  interactivamente  nos  ofrece  dos  opciones  para  corregirlo: 

1 . Introducir  un  valor  por  defecto,  para  rellenar  las  filas. 

2.  Salir  para  corregir  el  valor  por  defecto  en  los  modelos. 

Si  seleccionamos  la  primera  option,  se  inicia  el  interprete  interactivo  que  nos  pide 
agregar  un  valor  por  defecto,  siempre  y cuando  sea  un  valor  valido  en  Python,  la 
segunda  option  es  obvia,  es  tu  responsabilidad  corregir  el  modelo  manualmente 
usando  SQL. 

Una  vez  que  tengas  un  nuevo  archivo  de  migraciones,  debes  aplicarlo  a la  base  de 
datos  usando  el  comando  python  manage. py  migrate  para  cerciorarte  de  que  trabaja 
segun  lo  previsto: 

Operations  to  perform: 

Synchronize  unmigrated  apps:  sessions,  admin,  messages,  auth, 
staticfiles,  contenttypes 

Apply  all  migrations:  biblioteca 
Synchronizing  apps  without  migrations: 

Creating  tables . . . 

Installing  custom  SQL... 

Installing  indexes... 

Installed  0 object(s)  from  0 fixture(s) 

Running  migrations: 

Applying  libros . 0002_auto . . . OK 

El  comando  se  ejecuta  en  dos  etapas,  primero  sincroniza  las  aplicaciones  que  no 
han  sido  migradas  (sincronizando  los  cambios  en  los  modelos)  y segundo  ejecuta  las 
migraciones  que  no  han  sido  aplicadas.  Una  vez  que  una  migration  ha  sido  aplicada, 
esta  se  guarda  en  el  sistema  de  control  de  versiones. 
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Una  vez  realizados  los  cambios  inicia  el  interprete  interactivo,  y comprueba  que 
todo  trabaje  segun  lo  planeado: 

»>from  biblioteca. models  import  Libro 
»>Libro. objects. all()[:5] 

»> 

Eliminar  campos 

Eliminar  un  campo  de  un  modelo  es  mucho  mas  facil  que  agregar  uno.  Para  remover 
un  campo,  solo  sigue  estos  pasos: 

1.  Re mueve  el  campo  de  tu  modelo. 

2.  Ejecuta  el  comando  python  manage. py  makemigrations,  para  grabar  los 
cambios. 

3.  Elaz  los  cambios  en  la  base  de  datos  con  el  comando  python 
manage. py  migrate. 

4.  Y reinicia  el  servidor  Web. 

Asegurate  de  hacerlo  en  este  orden. 

Eliminar  relaciones  muchos  a muchos 


Debido  a que  los  campos  muchos  a muchos  son  diferentes  a los  campos  normales,  el 
proceso  de  elimination  es  un  poco  diferente. 

Para  eliminar  manualmente  una  relation  muchos  a muchos,  tendriamos  que  hacer 
lo  siguiente: 

1.  Re  mueve  el  campo  ManyToManyField  de  tu  modelo  y reinicia  el  servidor 
Web. 

2.  Remueve  la  tabla  muchos  a muchos  de  tu  base  de  datos  usando  un  comando 
SQL  como  este: 

DROP  TABLE  libros_libro_autores; 

Como  en  la  section  anterior,  podemos  seguir  los  siguientes  pasos,  para  usar  las 

migraciones: 

1.  Remueve  el  campo  muchos  a muchos  de  tu  modelo. 

2.  Ejecuta  el  comando  python  manage. py  makemigrations,  para  grabar  los 
cambios. 

3.  Elaz  los  cambios  en  la  base  de  datos  con  el  comando  python 
manage. py  migrate. 

4.  Reinicia  el  servidor  Web. 

Asegurate  de  hacerlo  en  este  orden  y asegurate  de  borrar  cualquier  modelo  que 
dependa  de  la  relation  muchos  a muchos,  de  otra  forma  no  funcionara. 
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Eliminar  modelos 

Eliminar  un  modelo  completo  es  tan  facil  como  agregar  uno.  Para  remover  un 
modelo,  solo  sigue  estos  pasos: 

1.  Remueve  el  modelo. 

2.  Ejecuta  el  comando  python  manage. py  makemigrations,  para  grabar  los 
cambios. 

3.  Elaz  los  cambios  en  la  base  de  datos  con  el  comando  python 
manage. py  migrate. 

4.  ReiniciaelservidorWeb. 

Manualmente  puedes  hacerlo  asi: 

1.  Elimina  el  modelo  de  tu  archivo  models.py  y reinicia  el  servidor. 

2.  Elimina  la  tabla  de  tu  base  de  datos,  usando  el  siguiente  comando: 

DROP  TABLE  bibliotecajibro; 


® Advertencia:  Ten  en  cuenta,  que  tambien  es  necesario  remover  cualquier  tabla 
que  dependa  de  el  modelo  que  quieras  borrar  de  tu  base  de  datos  primero  -por 
ejemplos  alguna  tabla  que  contenga  un  campo  foraneo  o una  relation  muchos  a 
muchos. 


Como  en  las  secciones  anteriores.  Asegurate  de  hacerlo  en  este  orden. 


Manejadores  o Managers 


En  la  declaration  Libro. objects. all(),  objects  es  un  atributo  especial  a traves  del  cual 
se  realizan  las  consultas  a la  base  de  datos.  En  el  C ap i t u 1 o Capit u/o5,  identificamos 
brevemente  a este  como  el  Manejador  (Manager).  Es  hora  de  sumergirnos  en  las 
profundidades  y conocer  que  son  los  manejadores  y como  podemos  usarlos. 

Un  Manager  es  la  interfaz  a traves  de  la  cual  se  proveen  las  operaciones  de  consulta 
de  la  base  de  datos  a los  modelos  de  Django.  Existe  al  menos  un  Manager  para  cada 
modelo  en  una  aplicacion  Django. 

Nombres  de  Manager 

Por  omision,  Django  agrega  un  Manager  llamado  objects  a cada  clase  modelo  de 
Django.  De  todas  formas,  si  tu  quieres  usar  objects  como  nombre  de  campo,  o 
quieres  usar  un  nombre  distinto  de  objects  para  el  Manager,  puedes  renombrarlo  en 
cada  uno  de  los  modelos.  Para  renombrar  el  Manager  para  una  clase  dada,  define  un 
atributo  de  clase  de  tipo  models. Manager!)  en  ese  modelo,  por  ejemplo: 
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from  django.db  import  models 

class  Persona(models. Model): 

...# 

gente  = models. Manager() 

Usando  este  modelo  de  ejemplo,  Persona.objects  generara  una  exception 
AttributeError  (dado  que  Persona  no  tiene  un  atributo  objects),  pero 
Persona.gente.allQ  devolvera  una  lista  de  todos  los  objetos  Persona. 


Managers  Personalizados 

Puedes  utilizar  un  Manager  personalizado  en  un  modelo  en  particular  extendiendo  la 
clase  base  Manager  e instanciando  tu  Manager  personalizado  en  tu  modelo. 

La  forma  en  que  trabajan  las  clases  Manager  esta  documentada  en  apendice  B. 
Esta  section  trata  especificamente  las  opciones  del  modelo  que  personaliza  el 
comportamiento  del  Manager. 

Elay  dos  razones  por  las  que  puedes  querer  personalizar  un  Manager:  para  agregar 
metodos  extra  al  Manager,  y/o  para  modificar  el  QuerySet  inicial  que  devuelve  el 
Manager. 


Agregando  Metodos  Extra  al  Manager 

Agregar  metodos  extra  al  Manager  es  la  forma  preferida  de  agregar  funcionalidad  a 
“nivel  de  tabla”  a tus  modelos.  (Para  agregar  funcionalidad  a nivel  de  registro  - esto 
es,  funciones  que  actuan  sobre  una  instancia  simple  de  un  objeto  modelo  - usa 
metodos  en  los  modelos,  los  cuales  son  explicados  mas  adelante  en  este  capitulo. 

Por  ejemplo,  demosle  al  Manager  de  nuestro  modelo  Libro  un  metodo 
contar_titulos(),  el  cual  toma  una  palabra  clave  y retorna  el  numero  de  libros  que 
contienen  un  titulo  que  contiene  dicha  palabra.  (Este  ejemplo  es  bastante  superficial, 
pero  demuestra  como  trabajan  los  Managers) 

# models. py 

from  django.db  import  models 

# ...  Los  modelos  Autor  y Editor  van  aqui ... 

class  ManejadorLibros(models. Manager): 
def  contar_titulos(self,  keyword): 

return  self.filter(titulo icontains=keyword).count() 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 
editores  = models.  ForeignKey(Editor) 

fecha_publicacion  = models. DateField(blank=  , null=  rue) 

num_paginas  = models. lntegerField(blank=  , null=  ) 

objects  = ManejadorLibros() 

def str (self): 

return  s .titulo 

Con  el  Manager  en  su  lugar,  ahora  podemos  hacer  esto: 
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»>  Libro. objects. contar_titulos('django') 

4 

»>  Libro. objects. contar_titulos('python') 

18 


Algunas  notas  sobre  el  codigo: 

■ Creamos  una  clase  ManejadorLibros  que  extiende  a la  clase 

django.db. models. Manager.  El  sencillo  metodo  contar_titulos(),  hace  los 
calculos.  Observa  que  el  metodo  usa  un  fdtro  self.filter(),  donde  self  se  reflere 
al  manager  en  si  mismo. 

■ Asignamos  ManejadorLibros ()  a los  atributos  de  objects  en  el  modelo.  Esto 
tiene  el  efecto  de  reemplazar  el  manejado  por  “defecto”,  el  cual  es  llamado 
objects  y es  automaticamente  creado  si  no  especificas  un  manager 
personalizado.  Lo  hemos  llamado  objects  en  vez  de  usar  algun  otro  nombre, 
para  ser  consistentes  con  los  managers  automaticamente  creados  por  Django. 

^Por  que  agregamos  un  metodo  tal  como  contar_titulos()  aqui?  Bueno,  para 
encapsular  la  ejecucion  de  consultas  comunes,  a fin  de  de  evitar  duplicar  el  codigo. 

Un  metodo  Manager  personalizado  puede  retornar  cualquier  cosa  que  necesites. 
No  tiene  que  retornar  un  QuerySet. 

Por  ejemplo,  este  Manager  personalizado  ofrece  un  metodo  contarO,  que  retorna 
una  lista  de  todos  los  objetos  Opinion,  cada  uno  con  un  atributo  extra 
num_respuestas;  que  es  el  resultado  de  una  consulta  agregada: 

from  django.db  import  models 

class  ManagerEncuestas(models. Manager): 
def  contar(self): 

from  django.db  import  connection 
cursor  = connection. cursor() 
cursor. execute(""" 

SELECT  p.id,  p.pregunta,  p.fecha,  COUNT(*) 

FROM  biblioteca_opinion  p,  biblioteca_respuesta  r 
WHERE  p.id  = r.encuestajd 
GROUP  BY  p.id,  p.pregunta,  p.fecha 

ORDER  BY  p.fecha  DESC ) 

lista_resultados  = [] 
for  row  in  cursor. fetchall(): 

p = self.model(id=row[0],  pregunta=row[l],  fecha=row[2]) 
p.num_respuestas  = row[3] 
lista_resultados.append(p) 
return  lista_resultados 

class  Opinio  (models. Model): 

pregunta  = models.  CharField(max_length=200) 
fecha  = models. DateField() 
objects  = ManagerEncuestas() 

class  Respuesta(models. Model): 

encuesta  = models.  ForeignKey(Opinion) 
nombre  = models.  CharField(max_length=50) 
respuesta  = models. TextFieldQ 
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En  este  ejemplo,  puedes  usar  Opinion.objects.contarO  para  retornar  la  lista  de 
objetos  Opinion  con  el  atributo  num  respuestas. 

Otra  cosa  a observar  en  este  ejemplo  es  que  los  metodos  de  un  Manager  pueden 
acceder  a self.model  para  obtener  la  clase  modelo  a la  cual  estan  anexados. 

Modificando  los  QuerySets  imciales  del  Manager 

Un  QuerySet  base  de  un  Manager  devuelve  todos  los  objetos  en  el  sistema.  Por 
ejemplo,  Libro. objects. all()  retornara  todos  los  libros  de  la  base  de  datos. 

Puedes  sobrescribir  el  QuerySet  base,  sobrescribiendo  el  metodo 
Manager.get_query_set().  get_query_set()  debe  retornar  un  QuerySet  con  las 
propiedades  que  tu  requieres. 

Por  ejemplo,  el  siguiente  modelo  tiene  dos  managers  - uno  que  devuelve  todos  los 
objetos,  y otro  que  retorna  solo  los  libros  de  Roald  Dahl: 

from  django.db  import  models 

# Primero,  definimos  una  subclase  para  el  Manager, 
class  Dahll_ibroManager(models. Manager): 

def  get_query_set(self): 

return  super(DahlLibroManager,  self). get_query_set().filter(autor- Roald  Dahl') 

# Despues  lo  anclamos  al  modelo  Libro  explicitamente. 

class  Libro(models. Model): 

titulo  = models. CharField(max_length=  .00) 
autor  = models.  CharField(max_length=5) 

# ... 

objects  = models. Manager()  # El  manager  predeterminado. 

dahl_objects  = DahlLibroManager()  # El  manager  Dahl”  especial. 

Con  este  modelo  de  ejemplo,  Libro. objects. all ()  retornara  todos  los  libros  de  la 
base  de  datos,  pero  Libro. dahl_objects.all()  solo  retornara  aquellos  escritos  por  Roald 
Dahl. 

Por  supuesto,  como  get_query_set()  devuelve  un  objeto  QuerySet,  puedes  usar 
filter 0,  exclude 0,  y todos  los  otros  metodos  de  QuerySet  sobre  el.  Por  lo  tanto,  todas 
estas  sentencias  son  legales: 

Libro. dahl_objects.all() 

Libro. dahl_objects.filter(titulo- Matilda') 

Libro. dahl_objects.count() 

Este  ejemplo  tambien  nos  muestra  otra  tecnica  interesante:  usar  varios  managers 
en  el  mismo  modelo.  Puedes  agregar  tantas  instancias  de  ManagerO  como  quieras. 
Esta  es  una  manera  facil  de  definir  “filters”  comunes  para  tus  modelos. 

Aqui  hay  un  ejemplo: 


class  ManejadorHombres(models. Manager): 
def  get_query_set(self): 

return  super(Manejadorhlombres,  se  f).get_query_set().filter(sexo- FT) 
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class  ManejadorMujeres(models. Manager): 
def  get_query_set(self): 

return  supe  (ManejadorMujeres,  ; l).get_query_set().filter(sexo='M') 

class  Persona(models. Model): 

nombre  = models.  CharField(max_length=50) 
apellido  = models. CharField(max_length=50) 

sexo  = models. CharField(max_length=l,  choices=(('M',  'Mujer'),  ('H',  'Hombre'))) 
gente  = models. Manager()  # EL  manejador  predeterm  inado. 

hombre  = ManejadorHombres()#  Devuelve  solo  hombres. 
mujer  = ManejadorMujeres()#  Devuelve  solo  mujeres. 

Este  ejemplo  te  permite  consultar  Persona.hombre.allO,  Persona.mujer.all(),  y 
Persona.gente.allO,  con  los  resultados  predecibles. 

Si  usas  objetos  Manager  personalizados,  toma  nota  que  el  primer  Manager  que 
encuentre  Django  (en  el  orden  en  el  que  estan  definidos  en  el  modelo)  tiene  un  status 
especial.  Django  interpreta  el  primer  Manager  definido  en  una  clase  como  el 
Manager  por  omision.  Ciertas  operaciones  - como  las  del  sitio  de  administration  de 
Django  - usan  el  Manager  por  omision  para  obtener  listas  de  objetos,  por  lo  que 
generalmente  es  una  buena  idea  que  el  primer  Manager  este  relativamente  sin  filtrar. 
En  el  ultimo  ejemplo,  el  manager  gente  esta  definido  primero  - por  lo  cual  es  el 
Manager  por  omision. 

En  resumen,  Un  Manager  es  la  interfaz  a traves  de  la  cual  se  proveen  las 
operaciones  de  consulta  de  la  base  de  datos  a los  modelos  de  Django.  Existe  al  menos 
un  Manager  para  cada  modelo  en  una  aplicacion  Django.  Puedes  crear  manejadores 
personalizados  para  modificar  el  acceso  a la  base  de  datos  para  requisitos 
particulares. 


Metodos  de  un  Modelo 


Define  metodos  personalizados  en  un  modelo  para  agregar  funcionalidad 
personalizada  a nivel  de  registro  para  tus  objetos.  Mientras  que  los  metodos  Manager 
estan  pensados  para  hacer  cosas  a nivel  de  tabla,  los  metodos  de  modelo  deben 
actuar  en  una  instancia  particular  del  modelo. 

Esta  es  una  tecnica  valiosa  para  mantener  la  logica  del  negocio  en  un  solo  lugar:  el 
modelo. 

Por  ejemplo,  este  modelo  tiene  algunos  metodos  personalizados: 

from  django.db  import  models 

class  Persona(models. Model): 

nombre  = models.  CharField(max_length=15) 
apellido  = models.  CharField(max_length=15) 
nacimiento  = models. DateField() 
domicilio  = models.  CharField(max_length=100) 
ciudad  = models.  CharField(max_length=15) 
estado  = models.  CharField(max_length=2) 

def  estatus_bebe(self): 

"Retorna  el  estatus  baby-boomer  de  la  persona." 
import  datetime 

if  datetime. date(1945,  8,  1)  <=  self.nacimiento  <=  datetime. date(1964,  12,  31): 
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return  "Baby  boomer" 

if  self.nacimiento  < datetime. date(1945,  8, 1): 
return  "Pre-boomer" 
return  "Post-boomer" 

def  es_del_medio_oeste(self): 

"Retorna  True  si  la  persona  nacio  en  el  medio-oeste." 
return  self.estado  in  ('IL',  'Wl',  'Ml',  'IN',  'OH',  'I A',  'MO') 

def  _nombre_completo(self): 

"Retorna  el  nombre  completo  de  una  persona." 
return  '%s  %s'  % (self.nombre,  self. 

Este  es  un  ejemplo  de  su  uso: 

»>  p = Persona. objects. get(nombre- Barack',  apellido-Obama) 

»>  p.nacimiento 

datetime. date(1961,  8,  4) 

»>  p.estatus_bebe() 

'Baby  boomer’ 

»>  p.es_del_medio_oeste() 

True 

»>  p.nombre_completo  # Nota  que  no  es  un  metodo  - es  tratado  como  un  atributo 
u’Barack  Obama’ 

Existe  tambien  un  punado  de  metodos  de  modelo  que  tienen  un  significado 
“especial”  para  Python  o Django.  Estos  metodos  se  describen  a continuation. 

Unicode 

El  metodo unicode_()  es  un  “metodo  magico”  de  Python  que  define  lo  que  debe 

ser  devuelto  si  llamas  a unicodeO  sobre  el  objeto.  Django  usa  unicode(obj)  (o  la 
funcion  relacionada  str(obj)  que  se  describe  mas  abajo)  en  varios  lugares, 
particularmente  como  el  valor  mostrado  para  hacer  el  render  de  un  objeto  en  el  sitio 
de  administracion  de  Django  y como  el  valor  insertado  en  un  plantilla  cuando 
muestra  un  objeto.  Por  eso,  siempre  debes  retornar  un  string  agradable  y legible  por 

humanos  en  el  formato  Unicode ()  de  un  objeto.  A pesar  de  que  esto  no  es 

requerido,  es  altamente  recomendado,  sobre  todo  usando  Python2X. 

Por  ejemplo: 

from  django.db  import  models 

class  Persona(models. Model): 

nombre  = models.  CharField(max_length=50) 
apellido  = models.  CharField(max_length=50) 

def Unicode (self): 

return  u’%s  %s’  % ( elf.nombre,  sell  .apellido) 

str 

str ()  es  un  “metodo  magico”  de  Python  que  define  lo  que  debe  ser  devuelto  si 

llamas  a str().  En  Python3,  Django  usa  str(obj),  en  varios  lugares,  particularmente 
como  el  valor  mostrado  para  hacer  el  render  de  un  objeto  en  el  sitio  de 
administracion  de  Django  y como  el  valor  insertado  en  un  plantilla  cuando  muestra 
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un  objeto.  Por  eso,  siempre  debes  retornar  un  string  agradable  y legible  por  humanos 

en  el  str de  un  objeto.  A pesar  de  que  esto  no  es  requerido,  es  altamente 

recomendado,  al  usar  Python3. 

Aqui  hay  un  ejemplo: 

class  Persona(models. Model): 

nombre  = models.  CharField(maxlength=50) 
apellido  = models.  CharField(maxlength=50) 

def str (self): 

return  '%s  %s'  % ( elf. nombre,  .apellido) 

_eq_ 

Un  metodo  de  igualdad  que  es  definido  cuando  las  instancias  con  la  misma  clave 
primaria  son  evaluadas  y la  clase  en  concreto  es  considerada  igual. 

Por  ejemplo: 

from  django.db  import  models 

class  MiModelo(models. Model): 

= models.AutoField(primary_key=  rue) 

class  ModeloProxy(MiModelo): 
class  Meta: 
proxy  = True 

class  HerenciaMultiple(MiModelo): 
pass 

MiModelo(  =1)  ==  MiModelo(  =1) 

MiModelo(  =1)  ==  ModeloProxy(  =1) 

MiModelo(  =1)  !=  HerenciaMultiple(id=l) 

MiModelo(  =1)  !=  MiModelo(  =2) 

hash 

Calcula  el  valor  hash  para  una  clave  primaria  de  cualquier  campo. 

El  metodo hash esta  basado  en  la  instancia  del  valor  de  la  clave  primaria. 

Usando  (obj.pk).  Si  la  instancia  no  tiene  una  clave  primaria  lanzara  un  error 
TypeError. 


get_absolute_url 

Define  un  metodo  get_absolute_url()  para  decide  a Django  como  calcular  la  URL  de 
un  objeto,  por  ejemplo: 

def  get_absolute_url(self): 
return  "/gente/%i/"  % elf.id 

Django  usa  esto  en  la  interfaz  de  administration.  Si  un  objeto  define 
get_absolute_url(),  la  pagina  de  edition  del  objeto  tendra  un  enlace  “View  on  site”, 
que  te  llevara  directamente  a la  vista  publica  del  objeto,  segun  get_absolute_url(). 
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Sin  embargo,  a pesar  de  que  este  codigo  es  simple,  no  es  muy  portable,  por  lo  que 
la  mejor  forma  de  aprovechar  esto  es  usando  la  funcion  reversed 
Por  ejemplo: 

def  get_absolute_url(self): 

from  django.core.urlresolvers  import  reverse 

return  reverse('gente. views. detalles',  args=[str(self.id)]) 

Tambien  un  par  de  otras  partes  de  Django,  como  el  framework  de  sindicacion  de 
feeds,  usan  get_absolute_url()  como  facilidad  para  recompensar  a las  personas  que 
han  definido  el  metodo. 


® Advertencia:  Debes  evitar  en  lo  posible,  construir  URL  para  entradas  no  validas, 
para  reducir  las  posibilidades  de  enlazar  contenidos  y redireccionamientos  no 
deseados  y potencialmente  peligrosos,  por  ejemplo: 

def  get_absolute_url(self): 
return  '/%s/'  % self.nombre 

Si  self.nombre  es  7example.com'  este  devolvera  7 /example. com/'  el  cual  es  un 
esquema  URL  valido,  pero  no  esperado. 


Es  una  buena  practica  usar  get_absolute_url()  en  plantillas,  en  lugar  de  codificar  en 
duro  las  URL  de  tus  objetos.  Por  ejemplo,  este  codigo  de  plantilla  es  mala. 

<!-  MALO  jNo  hagas  esto!  ->  <a  href=”/gente/{{  object. id  }}/”>{{  object.nombre  }}</a> 

Pero  este  es  bueno: 

<a  href=”{{  object. get_absolute_url  }}”>{{  object.nombre  }}</a> 

La  logica  aqui,  es  que  puedes  cambiar  la  estructura  completa,  de  las  URL  de  tus 
objetos,  en  un  unico  lugar  con  get_absolute_url(). 


Nota:  La  cadena  que  devuelve  el  metodo  get_absolute_url()  deve  contener 
unicamente  caracteres  ASCII  (requeridos  por  las  especificaciones  URI  RFC  2396)  y 
deben  ser  encodificadas  de  ser  necesario  (Django  provee  filtros  para  esto). 

Puedes  usar  la  funcion  django.utils.encoding.iri_to_uri()  para  realizar  este  trabajo 
y asi  garantizar  que  tus  cadenas  unicamente  contendran  caracteres  dentro  del  rango 
ASCII. 


Sobrescribir  metodos  predefinidos  de  un  modelo 


Existe  otro  conjunto  de  metodos  en  un  modelo  que  encapsulan  un  monton  de 
comportamientos  de  la  base  de  datos,  estos  pueden  ser  sobrescritos  para  requisitos 
particulares  que  quieras  modificar.  Particularmente  los  metodos  save()  y deleteO- 
Siente  libre  de  sobrescribir  estos  metodos  (y  cualquier  otro  metodo  de  un  modelo) 
para  alterar  su  comportamiento. 

Un  uso  clasico  para  sobrescribir  los  metodos  incorporados  de  un  modelo,  es  por 
ejemplo  si  quieres  que  pase  algo  cuando  guardas  un  objeto,  asi: 
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from  django.db  import  models 

class  Autoi  (models. Model): 

nombre  = models.  CharField(max_length=30) 
apellidos  = models.  CharField(max_length=40) 
email  = models.  EmailField() 

def  save(self,  *args,  **kwargs): 
haz_algo() 

super(Autor,  self).save(*args,  **kwargs)  # Llama  al  "verdadero"  metodo  save(). 

Tambien  puedes  evitar  guardar  un  objeto  en  especifico: 

from  django.db  import  models 

class  Autoi  (models. Model): 

nombre  = models.  CharField(max_length=30) 
apellidos  = models.  CharField(max_length=40) 
email  = models. EmailField() 

def  save(self,  *args,  **kwargs): 
if  self. nombre  ==  "Foo": 

return  # jFoo  ha  dicho  que  nunca  publicara  un  libro! 
else: 

super(Autor,  self).save(*args,  **kwargs)  # Llama  al  "verdadero"  metodo  save() 

Es  importante  recordar  llamar  el  metodo  de  los  superclase  - que  es  en  este  caso: 
super(Autor,  self).save(*args,  **kwargs)  para  asegurarse  de  que  el  objeto  se  ha 
guardado  en  la  base  de  datos,  ya  que  el  comportamiento  por  omision  no  toca  la  base 
de  datos  y el  objeto  no  se  guardara. 

Es  tambien  importante  pasar  los  argumentos  que  se  pueda  necesitar  pasar  al 
metodo  del  modelo  - que  son  *args,  **kwargs.  De  vez  en  cuando  en  Django,  se 
amplian  las  capacidades  incorporados  de  los  metodos  de  los  modelos,  agregando 
nuevos  argumentos.  Si  utilizas  *args  y **kwargs  en  tus  definiciones  del  metodo, 
garantizas  que  tu  codigo  soportara  automaticamente  esos  argumentos  cuando  se 
agreguen  mas. 


Ejecutando  consultas  personalizadas  en  SQL 

Algunas  veces  te  encontraras  con  que  la  API  de  bases  de  datos  de  Django  unicamente 
te  permite  realizar  un  cierto  tipo  de  consultas,  sientete  libre  de  escribir  sentencias 
SQL  personalizadas  en  metodos  personalizados  de  modelo  y metodos  a nivel  de 
modulo.  Es  muy  sencilla  accede  al  objeto  django.db. connection  el  cual  representa  la 
conexion  actual  a la  base  de  datos.  Para  usarla,  invoca  el  metodo  connection.cursor() 
para  obtener  un  objeto  cursor.  Despues,  llama  a cursor.execute(sql,  [params])  para 
ejecutar  sentencias  SQL,  y cursor.fetchoneO  o cursor. fetchall()  para  devolver  las  filas 
resultantes: 

Por  ejemplo: 

>»  from  django.db  import  connection 
»>  cursor  = connection. cursor() 

»>  cursor. execute( 

...  SELECT  DISTINCT  nombre 
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...  FROM  personas 

...  WHERE  apellido  = %s , ['Lennon']) 

»>  row  = cursor. fetchone() 

»>  print  row 
['John'] 

connection  y cursor  implementan  en  su  mayor  parte  la  API  de  bases  de  datos 
estandar  de  Python,  visita  ® http://www.python.org/peps/pep-0249.html,  si  no 
estas  familiarizado  con  la  API  de  bases  de  datos  de  Python,  observa  que  la  sentencia 
SQL  en  cursor.executeO  usa  marcadores  de  posicion,  "%s",  en  lugar  de  agregar  los 
parametros  directamente  dentro  del  SQL.  Si  usas  esta  tecnica,  la  biblioteca 
subyacente  de  base  de  datos  automaticamente  agregara  comillas  y secuencias  de 
escape  a tus  parametros  segun  sea  necesario.  (Observa  tambien  que  Django  espera  el 
marcador  de  posicion  "%s",  noe  1 marcadores  de  posicion  "?",  que  es  utilizado  por  los 
enlaces  de  Python  a SQLite  (Python  bindings)  Esto  es  por  consistencia  y salud 
mental. 

En  vez  de  ensuciar  el  codigo  de  tu  vista  con  esta  declaration 
django.db. connection,  es  una  buena  idea  ponerlo  en  un  metodo  personalizado  en  el 
modelo  o en  un  metodo  de  un  manager. 

De  esta  forma,  el  anterior  ejemplo  puede  ser  integrado  en  un  metodo  de  manager, 
asi: 

class  PersonaManager(models. Manager): 
def  nombres(self,  apellido): 
cursor  = connection. cursor() 
cursor. execute(""" 

SELECT  DISTINCT  apellido 
FROM  persona 

WHERE  apellido  = %s""",  [apellido]) 
return  [row[0]  for  row  in  cursor. fetchoneQ] 

class  Persona(models. Model): 

nombre  = models.  CharField(max_length=15) 
apellido  = models.  CharField(max_length=15) 
objects  = PersonaManager() 

Y este  es  un  ejemplo  de  su  uso: 

»>  Persona. objects.  nombres(Lennon') 

['John',  'Cynthia'] 


<?,Que  sigue? 

En  el  siguiente  capitulo,  te  mostraremos  el  framework  “Vistas  genericas”,  el  cual  te 
permite  ahorrar  tiempo  para  construir  sitios  Web,  que  siguen  patrones  comunes. 
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Vistas  Genericas 


^3  e nuevo  aparece  aqui  un  tema  recurrente  en  este  libro:  en  el  peor  de  los  casos,  el 
desarrollo  Web  es  aburrido  y monotono.  Hasta  aqui,  hemos  cubierto  como  Django 
trata  de  alejar  parte  de  esa  monotonia  en  las  capas  del  modelo  y las  plantillas,  pero 
los  desarrolladores  Web  tambien  experimentan  este  aburrimiento  al  nivel  de  las 
vistas. 

Las  vistas  genericas  basadas  en  clases  de  Django  fueron  desarrolladas  para 
aliviar  ese  dolor.  Recogen  ciertos  estilos  y patrones  comunes  encontrados  en  el 
desarrollo  de  vistas  y los  abstraen,  de  modo  que  puedas  escribir  rapidamente  vistas 
comunes  de  datos  sin  que  tengas  que  escribir  mucho  codigo.  De  hecho,  casi  todos  los 
ejemplos  de  vistas  en  los  capitulos  precedentes  pueden  ser  reescritos  con  la  ayuda  de 
vistas  genericas,  usando  clases. 

El  capltulo  8,  se  refirio  brevemente  a la  forma  de  crear  una  vista  “generica”.  Para 
repasar,  podemos  empezar  por  reconocer  ciertas  tareas  comunes,  como  mostrar  una 
lista  de  objetos,  y escribir  el  codigo  que  muestra  una  lista  de  detalle  de  cualquier 
objeto.  Por  lo  tanto  el  modelo  en  cuestion  puede  ser  pasado  como  un  argumento 
extra  a la  URLconf. 

Django  viene  con  vistas  genericas,  basadas  en  clases  para  hacer  lo  siguiente: 

■ Realizar  tareas  “sencillas”  y comunes:  como  redirigir  a una  pagina  diferente  a 
un  usuario  y renderizar  una  plantilla  dada. 

■ Mostrar  paginas  de  “listado”  y “detalle”  para  un  solo  objeto.  Por  ejemplo  una 
vista  para  presentar  una  lista  de  libros  y una  para  presentar  los  detalles  de  un 
libro  en  especifico,  la  primera  es  una  vista  de  listado,  una  pagina  de  objetos 
simples  que  muestra  la  lista  de  determinado  modelo,  mientras  el  segundo  es 
un  ejemplo  de  lo  que  llamamos  vista  “detallada”. 

■ Presentar  objetos  basados  en  fechas  en  paginas  de  archivo  de  tipo 
dia/mes/ano,  su  detalle  asociado,  y las  paginas  “mas  recientes”.  Los  archivos 
por  dia,  mes,  ano  del  blog  de  Django  http://www.djangoproject.com/weblog/ 
estan  construidos  con  ellas,  como  lo  estarian  los  tipicos  archivos  de  un 
periodico. 

■ Permitir  a los  usuarios  crear,  actualizar  y borrar  objetos  - con  o sin 
autorizacion. 

Agrupadas,  estas  vistas  proveen  interfaces  faciles  y sencillas  de  usar  para  realizar 
las  tareas  mas  comunes  que  encuentran  los  desarrolladores. 
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Introduccion  a las  clases  genericas 


Las  vistas  genericas  basadas  en  clases,  proveen  una  forma  alternativa  de  implementar 
vistas  como  objetos  Python  en  lugar  de  funciones.  No  remplazan  a las  funciones 
basadas  en  vista,  pero  poseen  ciertas  ventajas  y diferencias  si  las  comparamos  con  las 
vistas  basadas  en  funciones: 

■ Organizan  el  codigo  relacionado  en  metodos  especificos  HTTP  (GET,  POST, 
etc)  para  que  puedan  ser  tratados  por  metodos  especificos  en  lugar  de  tener 
que  tratar  cada  uno  por  separado. 

■ Usan  la  tecnica  de  orientation  a objetos  para  crear  “mixins”  (herencia 
multiple)  que  puede  ser  usada  para  factorizar  el  codigo  en  componentes 
comunes  y reutilizables. 

Como  mencionamos  en  capitulos  anteriores  una  vista  es  un  llamable  que  toma 
una  petition  y retorna  una  respuesta.  Pero  una  vista  puede  ser  mas  que  una  funcion, 
Y Django  provee  ejemplos  de  algunas  clases  que  pueden  ser  utilizadas  como  vistas. 
Estas  permiten  estructurar  las  vistas  y rehusar  el  codigo  aprovechando  los  mixins  y la 
herencia.  Existen  vistas  genericas  para  realizar  tareas  simples,  que  veremos  mas 
adelante,  sin  embargo  tambien  sirven  para  disenar  estructuras  personalizables  y 
reutilizables  que  facilmente  se  pueden  adaptar  a la  mayoria  de  caso  de  uso. 


Un  poco  de  historia 

La  conexion  y la  historia  de  las  vistas  genericas,  vistas  basadas  en  clase  y las  vistas 
genericas  basadas  en  clases-base,  puede  ser  un  poco  confusa,  sobre  todo  si  es  la 
primera  vez  que  escuchas  sobre  ellas. 

Inicialmente  solo  existian  funciones  basadas  en  vistas  genericas,  Django  pasaba  la 
funcion  en  una  petition  HttpRequest  y esperaba  de  vuelta  una  respuesta 
HttpResponse.  Ese  era  todo  el  alcance  que  Django  ofrecia. 

El  problema  con  las  funciones  genericas  basadas  en  vistas  es  que  solo  cubren  los 
casos  simples,  pero  no  permiten  extenderlas  y personalizarlas  mas  alia  de  la  simple 
configuration  de  opciones,  limitando  su  utilidad  en  muchas  aplicaciones  del  mundo 
real. 

Las  vistas  genericas  basadas  en  clases,  fueron  creadas  con  el  mismo  objetivo  que 
las  basadas  en  funciones,  hacer  el  desarrollo  mas  sencillo.  Por  lo  que  la  solution  se 
implemento  a traves  del  uso  de  “mixins”,  que  proveen  un  conjunto  de  herramientas, 
que  dieron  como  resultado  que  las  vistas  genericas  se  basaran  en  clases-base,  para 
que  fueran  mas  extensibles  y flexibles  que  su  contraparte  basadas  en  funciones. 

Si  usaste  las  funciones  genericas  para  crear  vistas  en  el  pasado  y las  encontraste 
limitadas  y deficientes,  no  debes  pensar  que  las  vistas  basadas  en  clases  son  su 
equivalente,  ya  que  funcionan  de  modo  diferente,  piensa  mas  en  ellas,  como  un 
acercamiento  fresco  para  solucionar  el  problema  original,  que  la  vistas  genericas 
tratan  de  solucionar,  “hacer  de  el  desarrollo  aburrido,  una  tarea  divertida”. 

El  conjunto  de  herramientas  que  proveen  las  clases  base  y los  “mixins”  que  Django 
usa  para  crear  clases  basadas  en  vistas  genericas,  nos  ayudan  a realizar  los  trabajos 
comunes  con  una  maxima  flexibilidad,  para  situaciones  simples  y complejas. 
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Usando  vistas  basadas  en  clases 

En  su  nucleo,  una  vista  basada  en  una  clase-base  permite  responder  a diferentes 
metodos  de  peticion  HTTP,  con  diversos  metodos  de  la  instancia  de  una  clase,  en 
lugar  de  condicionalmente  ramificar  el  codigo  dentro  de  una  simple  funcion  de  vista. 

Por  lo  que  el  codigo  para  manipular  HTTP  en  una  peticion  GET,  en  una  funcion  de 
vista  seria  algo  como  esto: 

from  django.http  import  HttpResponse 

def  mi_vista(request): 

if  request.method  ==  'GET': 

# <la  logica  de  la  vista> 

return  HttpResponse('resultado') 

Mientras  que  en  una  vista  basada  en  una  clase-base,  hariamos  esto: 

from  django.http  import  HttpResponse 
from  django. views. generic  import  View 

class  (View): 

def  get(self,  request): 

# <la  logica  de  la  vista> 

return  HttpResponse('resultado') 


Debido  a que  el  resolvedor  de  URL  de  Django  espera  enviar  la  peticion  y los 
argumentos  asociados  a una  funcion  llamable  no  a una  clase,  la  vistas  basadas  en 
clases  proven  un  metodo  interno  llamado  as_view(),  que  sirve  como  punto  de 
entrada  para  enlazar  la  clase  a la  URL.  El  punto  de  entrada  as_view()  crea  una 
instancia  de  la  clase  y llama  al  metodo  dispatchf),  (el  despachador  o resolvedor  de 
URL)  que  busca  la  peticion  para  determinar  si  es  un  GET,  POST,  etc,  y releva  la 
peticion  a un  metodo  que  coincida  con  uno  definido,  o levante  una  exception 
HttpResponseNotAllowed  si  no  encuentra  coincidencias. 

Y asi  es  como  enlazamos  la  clase  a la  URL,  usando  el  metodo  as_view() 

# urls.py 

from  django. conf.urls  import  url 
from  myapp. views  import  MiVista 

urlpatterns  = [ 

url(r'Aindice/',  MiVista. as_view()), 

] 


Vale  la  pena  observar  que  el  metodo  que  devuelve  es  identico  al  que  devuelve  una 
vista  basada  en  una  funcion,  a saber  una  cierta  forma  de  HttpResponse.  Esto  significa 
que  los  atajos  para  los  objetos  shortcuts  o TemplateResponse  son  validos  para  usar 
dentro  de  una  vista  basada  en  clases. 

Tambien  vale  la  pena  mencionar  que  mientras  que  una  vista  minima  basada  en 
clases,  no  requiere  ningun  atributo  de  clase  para  realizar  su  trabajo,  los  atributos  de 
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una  clase  son  utiles  en  muchos  de  los  disenos  de  las  clases-base.  Hay  dos  maneras  de 
configurar  los  atributos  de  una  clase. 

1.  El  primero  esta  basado  en  la  forma  estandar  de  Python  de  sobrescribir 
atributos  y metodos  en  las  subclases.  De  modo  que  si  una  clase  padre  tiene 
un  atributo  saludo  tal  como  este: 

from  django.http  import  HttpResponse 
from  django. views. generic  import  View 

class  VistaSaludo(View): 
saludo=  "Buenos  Dias" 

def  get(self,  request): 

return  HttpResponse(self.saludo) 

Puedes  sobrescribirlo  en  una  subclase  asi: 


class  VistaSaludolnformal(VistaSaludo): 
saludo=  "Que  onda" 

2.  La  segunda  option  es  configurar  los  atributos  de  la  clase  como  argumentos 
clave  para  el  metodo  as_view  de  django.views.generic.base.View.as_view, 
llamandolos  en  la  URLconf  asi: 

urlpatterns  = [ 

url(r'Aacerca/',  VistaSaludo.as_view(saludo="Que  tal")), 

] 


Nota:  Mientras  que  una  clase  es  instanciada  en  cada  petition  enviada  a ella,  los 
atributos  de  la  clase  fijados  a traves  del  punto  de  entrada  del  metodo  as_  view  ()  se 
configuran  solamente  una  vez;  cuando  se  importa  la  URLs. 


Vista  Base 


Django  proporciona  varias  vistas  basadas  en  clases,  las  cuales  se  adaptan  a una  gran 
variedad  de  aplicaciones.  Todas  las  vistas  heredan  de  la  clase-base  View  la  cual 
maneja  las  conexiones  de  la  vista  y las  URLs,  a traves  del  uso  de  metodos  HTTP  y 
otras  caracteristicas  simples.  Algunas  de  estas  vistas  son:  RedirectView  usada  para 
simple  redirecionamiento  HTTP,  TemplateView  la  cual  extiende  las  clases  base  para 
poder  renderizar  una  plantilla  cualquiera. 

Estas  tres  clases:  View,  TemplateView  y RedirectView  proveen  muchas  de  las 
funcionalidades  necesarias  para  crear  vistas  genericas  en  Django.  Puedes  pensar  en 
ellas  como  si  fueran  vista  padre  o superclases,  las  cuales  pueden  ser  usadas  en  si 
mismo  o heredar  de  ellas. 

Sin  embargo  no  puede  proveer  todas  las  capacidades  requeridas  para  un  proyecto 
en  general,  en  cuyo  caso  puedes  usar  los  mixins  y las  vistas  basadas  en  clases 
genericas,  como  complemento. 
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Muchas  de  las  vistas  construidas  sobre  clases  basadas  en  vistas,  heredan  de  otras 
vistas  genericas  tambien  basadas  en  clases  o de  varios  mixins.  Debido  a que  esta 
cadena  de  herencia  es  muy  importante,  el  manejo  de  ancestros  de  una  clases  se 
denomina  (MRO).  MRO  por  sus  siglas  en  ingles  para  Method  Resolution  Orden,  se 
encarga  de  resolver  el  orden  que  siguen  los  metodos  en  una  clase. 

View 

View  es  la  clase  base  maestra,  las  demas  vistas  heredan  de  esta  clase  base,  que 
pertenece  al  paquete  class  django.views. generic. base.  View. 

Flujo  de  los  metodos: 

1.  dispatch!):  El  resolvedor  de  URL's  de  la  vista  - es  decir  el  metodo  que  valida 
el  argumento  de  la  peticion,  mas  los  argumentos  recibidos  y devuelve  la 
respuesta  correcta  HTTP. 

Por  defecto  es  la  implementacion  que  inspecciona  el  metodo  HTTP  y 
tentativamente  la  delega  al  metodo  que  coincida  con  la  peticion  HTTP;  por 
ejemplo  una  peticion  GET  sera  delegado  a un  metodo  get(),  un  POST  a un 
post(),  y asi  sucesivamente. 

2.  http_method_not_allowed():  Si  la  vista  es  llamada  con  un  metodo  HTTP  no 
soportado,  este  metodo  es  llamado  en  su  lugar. 

La  implementacion  por  defecto  retorna  un  HttpResponseNotAllowed  con  una 
lista  de  metodos  permitidos  en  texto  piano. 

3.  options!):  Manejadores  que  responden  a las  peticiones  OPTIONS  HTTP. 
Retorna  una  lista  de  no  mb  res  permitidos  al  metodo  HTTP  para  la  vista 

Ejemplo: 

views.py: 

from  django.http  import  HttpResponse 
from  django.views. generic  import  View 

class  MiVista(View): 

def  get(self,  request,  *args,  **kwargs): 
return  HttpResponse('Hola,  Mundo') 

urls.py; 

from  django.conf.urls  import  url 
from  myapp. views  import  MiVista 

urlpatterns  = [ 

url(r'Ahola/$',  Mi  Vista.  as_view(),  name- mi-vista'), 

] 

Por  defecto  la  lista  de  nombres  de  metodos  HTTP  que  la  vista  'View  puede  aceptar 
son:  'get',  'post',  'put',  'patch',  'delete',  'head',  'options',  'trace'. 
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TemplateView 

La  clase  TemplateView  renderiza  una  plantilla  dada,  con  el  contexto  que  contiene  los 
parametros  capturados  en  la  URL,  esta  clase  pertenece  al  paquete  class 
django.views.generic.base.TemplateView 

Ancestros  (MRO) 

Esta  vista  hereda  atributos  y metodos  de  las  siguientes  vistas: 

■ django.views.generic.base.TemplateResponseMixin 

■ django.views.generic.base.ContextMixin 

■ django.views.generic.base.View 

Flujo  de  los  metodos: 

1.  dispatch!) : Valida  la  petition  (ver  arriba) . 

2.  http_method_not_allowed():  Verifica  los  metodos  soportados. 

3.  get_context_data():  Se  encarga  de  pasarle  el  contexto  (context)  a la  vista. 
Ejemplo: 

views.py: 

from  django. views. generic. base  import  TemplateView 
from  biblioteca. models  import  Libro 

class  Paginalnicio(TemplateView): 
template_name  = "bienvenidos.html" 
def  get_context_data(self,  **kwargs): 

context  = (Paginalnicio,  lf).get_context_data(**kwargs) 
context['ultimos_libros']  = Libro. objects. all()[:5] 
return  context 

urls.py: 

from  django. conf.urls  import  url 

from  biblioteca. views  import  Paginalnicio 

urlpatterns  = [ 

url(r'A$',  Paginalnicio. as_view(),  name- bienvenidos'), 

] 


La  clase  TemplateView  rellena  el  contexto  (a  traves  de  la  clase 
django.views.generic.base.ContextMixin)  con  los  argumentos  clave  capturados  en  el 
patron  URL,  que  sirve  a la  vista. 
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RedirectView 

La  clase  RedirectView  tal  como  su  nombre  lo  indica,  simplemente  redirecciona  una 
vista  con  la  URL  dada. 

La  URL  dada  puede  contener  un  formato  de  estilo  tipo  diccionario,  que  sera 
intercalado  contra  los  parametros  capturados  en  la  URL.  Ya  que  el  intercalado  de 
palabras  claves  se  hace  siempre  (incluso  si  no  se  le  pasan  argumentos),  por  lo  que 
cualquier  caracter  como  "%"  (un  marcador  de  posicion  en  Python)  en  la  URL  debe 
ser  escrito  como  %%"  de  modo  que  Python  lo  convierta  en  un  simple  signo  de 
porcentaje  en  la  salida. 

Si  la  URL  dada  es  None,  Django  retornara  una  respuesta  HttpResponseGone  (410). 
Ancestros  (MRO) 

Esta  vista  hereda  los  metodos  y los  atributos  de: 
dj  ango  .views . generic  .base  .Vie  w 
Flujo  de  los  metodos: 

1.  dispatchO 

2.  http_method_not_allowed() 

3.  get_redirect_urlO : Construye  el  URL  del  objetivo  para  el  redireccionamiento. 
La  implementacion  por  defecto  usa  la  url  como  la  cadena  de  inicio  para 
realizar  la  expansion  mediante  el  marcador  de  posicion  % en  la  cadena 
usando  el  grupo  de  nombres  capturados  en  la  URL. 

Si  no  se  configura  el  atributo  url,  mediante  el  metodo  get_redirect_url() 
entonces  Django  intenta  invertir  el  nombre  del  patron,  usando  los 
argumentos  capturados  en  la  URL  (usando  los  grupos  cony  sin  nombre). 

Si  es  una  peticion  de  un  atributo  query_string  tambien  se  agregara  a la  cadena  de 
consul ta  generada  por  la  URL.  Las  subclases  pueden  ejecutar  cualquier 
comportamiento  que  deseen,  mientras  que  el  metodo  devuelva  una  cadena  de 
redireccionamiento  a una  URL. 

Los  atributos  de  esta  clase  son: 

■ url:  La  URL  para  redireccionar  la  vista,  en  formato  de  cadena  o un  valor  None 
para  lanzar  un  error  HTTP  410. 

■ pattern_name:El  nombre  de  el  patron  URL  para  redirecionar  la  vista.  El 
redireccionamiento  puede  ser  hecho  usando  los  mismos  args  y kwargs  que  se 
pasan  a las  vistas. 

■ permanent:  Se  usa  solo  si  el  redireccionamiento  debe  ser  permanente.  La 
unica  diferencia  aqui  es  el  codigo  de  estado  devuelto  por  la  peticion  HTTP.  Si 
es  True,  entonces  el  redireccionamiento  utiliza  el  codigo  de  estado  301.  Si  es 
False,  entonces  el  redireccionamiento  utiliza  el  codigo  de  estado  302.  Por 
defecto,  permanent  es  True. 

■ query_string:Cualquier  cosa  que  se  le  pase  a la  consulta  usando  el  metodo 
GET  a la  nueva  localizacion.  Si  es  True,  entonces  la  consulta  se  anade  al  final 
de  la  URL.  Si  es  False,  entonces  la  consulta  se  desecha.  Por  defecto, 
query_string  es  False. 
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Ejemplo: 

views.py: 

from  django. shortcuts  import  get_object_or_404 
from  django.views. generic. base  import  RedirectView 
from  biblioteca. models  import  Libro 

class  ContadorLibrosRedirectView(RedirectView): 

permanent  = False 
query_string  = rue 
pattern_name  = detalle-libro' 

def  get_redirect_url(self,  *args,  **kwargs): 

libro  = get_object_or_404(Libro,  pk=kwargs['pk']) 
libro.  update_counter() 
return  (ContadorLibrosRedirectView, 
lf).get_redirect_url(*args,  **kwargs) 


urls.py: 

from  django. conf.urls  import  url 

from  django. views. generic. base  import  RedirectView 

from  biblioteca. views  import  ContadorLibrosRedirectView,  DetalleLibro 

urlpatterns  = [ 

url(r'Acontador/(?P<pk>[0-9]+)/$',  ContadorLibrosRedirectView.as_view(), 
name-contador-libros'), 

url(r'Adetalles/(?P<pk>[0-9]+)/$',  DetalleLibro. as_view(), 
name-detalles-libro'), 

url(r'Air-a-django/$',  RedirectView.as_view(url='http://djangoproject.com'), 
name='ir-a-django'), 

] 


Vistas  genericas  basadas  en  clases  usando 

URLconfs 

La  manera  mas  simple  de  utilizar  las  vistas  genericas  es  creandolas  directamente  en 
la  URLconf.  Si  unicamente  quieres  cambiar  algunos  atributos  en  una  vista  basada  en 
clases-base,  puedes  simplemente  pasarle  los  atributos  que  quieres  sobrescribir 
dentro  del  metodo  as_view,  ya  que  este  es  un  llamable  en  si  mismo. 

Por  ejemplo,  esta  es  una  URLconf  simple  que  podrias  usar  para  presentar  una 
pagina  estatica  “acerca  de”,  usando  una  vista  generica: 


from  django. conf.urls  import  url 

from  django. views. generic  import  TemplateView 

urlpatterns  = [ 

url(r'Aacerca/',  TemplateView.as_view(template_name="acerca_de.html")), 
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Cualquier  argumento  pasado  al  metodo  as_view  sobrescribira  los  atributos  fijados 
en  la  clase.  En  este  ejemplo,  hemos  configurado  el  nombre  de  la  plantilla  con  la 
variable  template_name  en  la  URLconf,  de  la  vista  TemplateView.  Un  patron  similar 
se  puede  utilizar  para  sobrescribir  atributos  en  la  clase  RedirectView. 

Aunque  esto  podria  parecer  un  poco  “magico”  a primera  vista,  en  realidad  solo 
estamos  usando  la  clase  TemplateView,  la  cual  renderiza  una  plantilla  dada,  con  el 
contexto  dado,  sobrescribiendo  el  nombre  de  la  plantilla  y los  atributos  predefinidos 
en  la  clase  base  TemplateView. 

Vistas  genericas  basadas  en  clases  usando 

subclases 


La  segunda  forma  mas  poderosa  de  usar  las  vistas  genericas  es  hacer  que  estas 
hereden  de  una  vista  sobrescribiendo  sus  atributos  (tal  como  el  nombre  de  la 
plantilla)  o sus  metodos  (como  get_context_data  ) en  una  subclase  que  proporcione 
nuevos  valores  o metodos.  Considera  por  ejemplo  una  vista  que  muestre  una 

plantilla  acerca_de.html.  Django  posee  una  vista  generica  que  hace  este  trabajo, 
como  lo  vimos  en  el  ejemplo  anterior  - TemplateView  solo  es  necesario  crear  una 
subclase  que  sobrescriba  el  nombre  de  la  plantilla  asi: 


biblioteca/views .py 


from  django. views. generic  import  TemplateView 

class  VistaAcercaDe(TemplateView): 

template_name  = "acerca_de.html" 

Despues  lo  unico  que  necesitas  es  agregar  la  nueva  vista  a la  URLConf.  La  clase 
TemplateView  no  es  una  funcion,  asi  que  apuntamos  la  URL  usando  un  metodo 
interno  as_view()  de  la  clase  en  su  lugar,  el  cual  provee  una  entrada  como  si  fuera  una 
funcion  a la  vista  basada  en  una  clases-base. 


biblioteca/urls .py 


from  django. conf.urls  import  url 
from  aplicacion.views  import  AboutView 

urlpatterns  = [ 

u rl(r'Aacerca/' , VistaAcercaDe. as_view()) , 

] 


Cualquier  argumento  pasado  al  metodo  as_view()  sobrescribira  los  definidos  en  la 
clase  recien  creada. 


Vistas  genericas  de  objetos 

La  vista  generica  TemplateView  ciertamente  es  util,  pero  las  vistas  genericas  de 
Django  brillan  realmente  cuando  se  trata  de  presentar  vistas  del  contenido  de  tu  base 
de  datos.  Ya  que  es  una  tarea  tan  comun,  Django  viene  con  un  punado  de  vistas 
genericas  incluidas  que  hacen  la  generation  de  vistas  de  listado  y detalle  de  objetos 
increiblemente  facil. 
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Comenzaremos  observado  algunos  ejemplos  basicos,  sobre  como  mostrar  una 
lista  de  objetos  usando  la  vista  generica  basada  en  clases  llamada  ListView  y como 
mostrar  objetos  de  forma  individual,  usando  la  clase  generica  DetailView. 

Usaremos  el  modelo  Editor  creado  en  capitulos  anteriores: 


biblioteca/models . py 


from  django.db  import  models 

class  Editor(models. Model): 

nombre  = models.  CharField(max_length=30) 
domicilio  = models.  CharField(max_length=50) 
ciudad  = models.  CharField(max_length=60) 
estado  = models.  CharField(max_length=30) 
pais  = models.  CharField(max_length=50) 
website  = models. URLField() 

def str (self):  # Unicode en  Python  2 

return  self. nombre 

Primero  definimos  una  vista,  para  crear  una  lista  de  editores,  usando  una  clase 
generica  llamada  ListView: 


biblioteca/views .py 


from  django. views. generic  import  ListView 
from  biblioteca.models  import  Editor 

class  ListaEditores(ListView): 

model  = Editor 

Como  puedes  ver  la  clase  ListView  pertenece  a la  clase 
django.views.generic.list.ListView  la  cual  se  encarga  de  presentar  un  listado  de  todos 
los  objetos  de  un  modelo,  piensa  en  ListView  como  una  consulta  del  tipo 
Editor. objets.all().  Cuando  esta  vista  es  ejecutada  llama  al  metodo  self.objecLjist  el 
cual  contiene  una  lista  de  objetos  (usualmente,  pero  no  necesariamente  un  queryset) 

Despues  importamos  la  vista  y la  enlazamos  directamente  a la  urls,  usando  el 
metodo  as_view(),  es  como  decide  a Django:  esta  clase  es  una  vista: 


urls .py 


from  django. conf.urls  import  url 

from  biblioteca. views  import  ListaEditores 

urlpatterns  = [ 

url(r'Aeditores/$',  ListaEditores. as_view(),  name-lista-editores' ), 

] 


Ese  es  todo  el  codigo  Python  que  necesitamos  escribir,  para  presentar  un  listado 
de  objetos  de  un  modelo.  Sin  embargo,  todavia  necesitamos  escribir  una  plantilla. 
Podriamos  decirle  explicitamente  a la  vista  que  plantilla  debe  usar  incluyendo  un 
atributo  template_name,  pero  en  la  ausencia  de  una  plantilla  explicita  Django  inferira 
una  del  nombre  del  objeto.  En  este  caso,  la  plantilla  inferida  sera 
"biblioteca/editorjist.html"  - la  parte  “biblioteca”  proviene  del  nombre  de  la 
aplicacion  que  define  el  modelo,  mientras  que  la  parte  “editor”  es  solo  la  version  en 
minusculas  del  nombre  del  modelo,  mas  el  sufijo  _list. 
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Nota:  El  cargador  de  plantillas  esta  activado  de  forma  predeterminada,  en  el 
archivo  de  configuration,  en  la  variable  TEMPLATE_LOADERS,  por  lo  que  el 
directorio  predeterminado  donde  Django  buscara,  las  plantillas  sera:  en  el 
directorio:  /ruta/a/proyecto/biblioteca/templates/biblioteca/editor_list.html. 


Django  por  omision  busca  un  directorio  con  el  nombre  de  la  aplicacion  dentro  del 
directorio  de  plantillas  llamado  templates,  dentro  de  cada  aplicacion  registrada. 

Esta  plantilla  sera  renderizada  con  un  contexto  que  contiene  una  variable  llamada 
object_list  la  cual  contiene  todos  los  objetos  “editor”  del  modelo. 

Una  plantilla  muy  simple  podria  verse  de  la  siguiente  manera: 


biblioteca/templates/biblioteca/editor_list . html 


{%  extends  "base.html"  %} 

{%  block  content  %} 

<h2>Editores</h2> 

{%  if  object Jist  %} 

<ul> 

{%  for  editores  in  objectjist  %} 

<li><a  href="{%  url  'detalles-editor'  editores. pk  %}"> 

{{ editores. nombre  }}</a></li> 

{%  endfor  %} 

</ul> 

{%  else  %} 

<p>No  hay  editores  registrados.</p> 

{%  endif  %} 

{%  endblock  %} 

(Observa  que  esta  plantilla  asume  que  existe  una  plantilla  base  (en  el  directorio 
superior  templates),  llamada  "base.html",  de  la  cual  hereda,  tal  y como  vimos  en  los 
ejemplos  del  capitulo  4,  tambien  asumen  que  existe  una  url  llamada  detalles-editor, 
la  cual  crearemos  a continuation.) 

Ciertamente  obtener  una  lista  de  objetos  con  la  clase  generica  ListView  es  siempre 
muy  util,  pero  que  pasa  si  queremos  mostrar  un  solo  objeto,  por  ejemplo  los  detalles 
de  un  determinado  editor,  en  ese  caso  usamos  la  vista  generica  DetailView,  que  se 
encarga  de  presentar  los  detalles  de  un  objeto,  ejecutando  self.object  el  cual 
contendra  el  objeto  sobre  el  que  la  vista  esta  operando. 

Por  ejemplo  si  quisieramos  mostrar  un  editor  en  particular,  usariamos  la  clase: 
DetailView,  de  esta  manera: 


biblioteca/views .py 


from  django. views. generic. detail  import  DetailView 
from  biblioteca.models  import  Editor 

class  DetallesEditor(DetailView): 

model  = Editor 

AL  igual  que  con  la  vista  anterior,  solo  necesitamos  importarla  y enlazar  la  vista  a 
su  respectiva  URL  asi: 
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urls .py 


from  django.conf.urls  import  url 

from  biblioteca. views  import  DetallesEditor 

urlpatterns  = [ 

url(r'Adetalles/editor/(?P<pk>[0-9]+)/$',  DetallesEditor.as_view(), 
name-detalles-editor' ), 

] 


Y por  ultimo  creamos  la  plantilla  con  el  nombre  por  defecto  que  le  asigna  Django 
que  es  editor_detail.html: 


biblioteca/templates/biblioteca/editor_detail . html 


{%  extends  ’’base. html"  %} 

{%  block  content  %} 

<h2>Editor:  {{  editor. nombre  }}</h2> 

<ul> 

<li>Domicilio:  {{  editor. domicilio  }}</li> 

<li>Ciudad:  {{  editor. ciudad  }}</li> 

<li>Estado:  {{  editor. estado  }}</li> 

<li>Pais:  {{  editor. pais  }}</li> 

<li>Sitio  web:  {{  editor. website  }}</li> 

</ul> 

<p><a  href="{%  url  lista-editores'  %}">Lista  de  editores</a></p> 

{%  endblock  %} 

Observa  que  accedemos  al  contexto  usando  el  nombre  en  minusculas  del  modelo. 

ListView  y DetailView  son  las  dos  vistas  basadas  en  clases  genericas  que 
probablemente  se  usen  mas  en  el  diseno  de  proyectos. 

Eso  es  realmente  todo  en  lo  referente  al  tema.  Todas  las  geniales  caracteristicas  de 
las  vistas  genericas  provienen  de  cambiar  los  atributos  fijados  en  la  vista  generica.  El 
Apendice  C documenta  todas  las  vistas  genericas  y todas  sus  opciones  en  detalle;  el 
resto  de  este  capitulo  considerara  algunas  de  las  maneras  mas  comunes  en  que 
puedes  personalizar  y extender  las  vistas  genericas  basadas  en  clases. 


Extender  las  vistas  genericas 

No  hay  duda  de  que  usar  las  vistas  genericas  puede  acelerar  el  desarrollo 
sustancialmente.  En  la  mayoria  de  los  proyectos,  sin  embargo,  llega  un  momento  en 
el  que  las  vistas  genericas  no  son  suficientes.  De  hecho,  la  pregunta  mas  comun  que 
se  hacen  los  nuevos  desarrolladores  de  Django  es  como  hacer  para  que  las  vistas 
genericas  manejen  un  rango  mas  amplio  de  situaciones. 

Afortunadamente,  en  casi  cada  uno  de  estos  casos,  hay  maneras  de  simplemente 
extender  las  vistas  genericas  para  manejar  un  conjunto  mas  amplio  de  casos  de  uso. 
Estas  situaciones  usualmente  recaen  en  un  punado  de  patrones  que  se  tratan  en  las 
secciones  que  siguen. 
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Crear  contextos  de  plantilla  “amistosos” 

Tal  vez  hayas  notado  que  el  ejemplo  de  la  plantilla  editores  almacena  la  lista  de  todos 
los  editores  en  una  variable  llamada  objecljist.  Aunque  esto  funciona  bien,  no  es  una 
forma  “amistosa”  para  los  autores  de  plantillas:  ellos  solo  tienen  que  “saber”  que 
estan  trabajando  con  una  lista  de  editores. 

Bien,  si  estas  tratando  con  un  objeto  de  un  modelo,  el  trabajo  esta  hecho.  Cuando 
estas  tratando  con  un  objeto  o queryset,  Django  es  capaz  de  rellenar  el  contexto 
usando  el  nombre  de  la  clase  en  minusculas  de  un  modelo,  mas  _list.  Esto  es  provisto 
ademas  de  la  entrada  predeterminada  object_list,  pero  conteniendo  exactamente  los 
mismos  datos,  por  ejemplo  editor_list,  es  equivalente  a object_list. 

Si  el  nombre  no  es  una  buena  idea,  puedes  manualmente  cambiarlo  en  el  contexto 
de  la  variable.  El  atributo  context_object_name  en  una  vista  generica  especifica  el 
contexto  de  las  variables  a usar: 


biblioteca/views .py 


from  django. views. generic  import  ListView 
from  biblioteca.models  import  Editor 

class  ListaEditores(ListView): 

model  = Editor 

context_object_name  = 'lista_editores' 

Proporcionar  utiles  nombres  de  contexto  (context_object_name)  es  siempre  una 
buena  idea,  tus  companeros  de  trabajo  que  disenan  las  plantillas  te  lo  agradeceran. 

Agregar  un  contexto  extra 

A menudo  simplemente  necesitas  presentar  alguna  informacion  extra  aparte  de  la 
proporcionada  por  la  vista  generica.  Por  ejemplo,  piensa  en  mostrar  una  lista  de 
todos  los  libros  en  cada  una  de  las  paginas  de  detalle  de  un  editor. 

La  vista  generica  DetailView,  que  pertenece  a la  clase 

django.views.generic.detail.DetailView  provee  el  contexto  a editores,  ^Pero  como 
obtener  informacion  adicional  en  la  plantilla? 

La  respuesta  esta  en  la  misma  clase  DetailView,  que  provee  su  propia 

implementacion  del  metodo  get_context_data,  la  implementacion  por  defecto 
simplemente  agrega  un  objeto  para  mostrar  en  la  plantilla,  pero  puede  sobrescribirse 
aun  mas: 


biblioteca/views .py 


from  django. views. generic  import  DetailView 
from  biblioteca.models  import  Editor,  Libro 

class  DetallesEditor(DetailView): 

model  = Editor 

context_object_name  = 'editor' 

def  get_context_data(self,  **kwargs): 

# Llama  primero  a la  implementacion  para  traer  un  contexto 

context  = super (DetallesEditor,  self).get_context_data(**kwargs) 

# Agrega  un  QuerySet  para  obtener  todos  los  libros 

context['lista_libros']  = Libro.  objects.  all() 
return  context 
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Con  esta  vista  obtenemos  dos  queryset,  "editor"  que  muestra  los  detalles  de  un 
editor  en  especifico  y "lista_libros"  que  obtiene  todos  los  libros  de  la  base  de  datos. 


Nota:  Por  lo  general  get_context_data  combina  los  datos  del  contexto  de  todas  las 
clases  padres  con  los  de  la  clase  actual.  Para  conservar  este  comportamiento  en  las 
clases  donde  se  quiera  alterar  el  comportamiento  del  contexto,  asegurate  de  llamar  a 
get_context_data  en  la  super  clase.  Cuando  ninguna  de  las  dos  clases  trate  de  definir 
la  misma  clave,  esto  dara  los  resultados  esperados.  Sin  embargo  si  cualquiera  de  las 
clases  trata  de  sobrescribir  la  clave  despues  de  que  la  clase  padre  la  ha  fijado 
(despues  de  llamar  a super)  cualquiera  de  las  clases  hija  necesitara  explicitamente 
fijarla  y asegurarse  de  sobrescribir  todas  las  clases  padres.  Si  tienes  problemas,  revisa 
el  orden  de  resolution  del  metodo  de  una  vista. 


Vista  para  un  subconjunto  de  objetos 


Ahora  echemos  un  vistazo  mas  de  cerca  al  argumento  model  que  hemos  venido 
usando  hasta  aqui.  El  argumento  model  especifica  el  modelo  de  la  base  de  datos  que 
usara  la  vista  generica,  la  mayoria  de  las  vistas  genericas  usan  uno  de  estos 
argumentos  para  operar  sobre  un  simple  objeto  o una  coleccion  de  objetos.  Sin 
embargo  El  argumento  model  no  es  la  unica  forma  de  especificar  los  objetos  que  se 
mostraran  en  la  vista,  puedes  especificar  una  lista  de  objetos  usando  como 
argumentos  un  queryset 

from  django. views. generic  import  DetailView 
from  biblioteca.models  import  Editor 

class  DetallesEditor(DetailView): 

context_object_name  = 'editor' 
queryset  = Editor. objects. all() 


Especificando  model  = Editor  es  realmente  un  atajo  para  decir:  queryset  = 
Editor. objects. all().  Sin  embargo,  usando  un  queryset  puedes  filtrar  una  lista  de 
objetos  y puedes  especificar  los  objetos  que  quieres  que  se  muestren  en  la  vista. 

Para  escoger  un  ejemplo  simple,  puede  ser  que  quieras  ordenar  una  lista  de  libros 
por  fecha  de  publication,  con  los  libros  mas  reciente  al  inicio: 

from  django. views. generic  import  ListView 
from  biblioteca.models  import  Libro 

class  LibrosRecientes(ListView): 

queryset  = Libro. objects. order_by('-fecha_publicacion') 
context_object_name  = 'libros_recientes' 


Este  es  un  ejemplo  bastante  simple,  pero  ilustra  bien  la  idea.  Por  supuesto,  tu 
usualmente  querras  hacer  mas  que  solo  reordenar  objetos.  Si  quieres  presentar  una 
lista  de  libros  de  un  editor  en  particular,  puedes  usar  la  misma  tecnica: 
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from  django. views. generic  import  ListView 
from  biblioteca.models  import  Libro 

class  LibroAcme(ListView): 

context_object_name  = 'lista_libros_acme' 

queryset  = Libro. objects. filter(editor nombre- Editores  Acme') 

template_name  = 'biblioteca/lista_libros_acme.htmr 


Observa  que  ademas  de  filtrar  un  queryset,  tambien  estamos  usando  un  nombre 
de  plantilla  personalizado.  Si  no  lo  hicieramos,  la  vista  generica  usaria  la  misma 
plantilla  que  la  lista  de  objetos  “generica”,  que  puede  no  ser  lo  que  queremos. 

Tambien  observa  que  esta  no  es  una  forma  muy  elegante  de  hacer  una  lista  de 
editores-especificos  de  libros.  Si  queremos  agregar  otra  pagina  de  editores, 
necesitamos  otro  punado  de  lineas  en  la  URLconf,  y mas  de  unos  cuantos  editores  no 
sera  razonable.  Enfrentaremos  este  problema  en  la  siguiente  section. 


Nota:  Si  obtienes  un  error  404  cuando  solicitas  /libros /acme/,  para  estar  seguro, 
verifica  que  en  realidad  tienes  un  Editor  con  el  nombre  'Editores  Acme'.  Las  vistas 
genericas  proveen  un  parametro  extra  allow_empty  para  estos  casos.  Mira  el 
Apendice  D para  mayores  detalles. 


Filtrado  Dinamico 

Otra  necesidad  muy  comun  es  filtrar  los  objetos  que  se  muestran  en  una  pagina  de 
listado  por  alguna  clave  en  la  URLconf.  Anteriormente  codificamos  el  nombre  de  los 
editores  en  la  URLconf,  pero  £que  pasa  si  queremos  escribir  una  vista  que  muestre 
todos  los  libros  por  algun  editor  arbitrario? 

Podemos  “usar”  la  vista  generica  ListView  que  posee  un  metodo  get_queryset  que 
pertenece  a la  clase  django.views.generic.list.MultipleObjectMixin.get_queryset  el 
cual  sobrescribimos  anteriormente,  el  cual  retornaba  el  valor  del  atributo  queryset, 
pero  ahora  le  agregaremos  mas  logica. 

La  parte  crucial  para  hacer  este  trabajo  esta  en  llamar  a las  vistas  basadas  en 
clases-base,  ya  que  guardan  algunas  cosas  utiles  con  self;  tal  como  la  petition 
(self.request)  esta  incluye  la  position  (self.args)  el  nombre  base  (self.kwargs)  los 
argumentos  capturados  acorde  a la  URLconf. 

Esta  es  una  URLconf  con  un  unico  grupo  capturado: 


urls .py 


from  django. conf.urls  import  url 

from  biblioteca. views  import  ListaLibrosEditores 

urlpatterns  = [ 

url(r'Alibros/([\w-]+)/$',  ListaLibrosEditores. as_view(),  name-lista-libros-editor  ), 

] 


A continuation,  escribimos  la  vista  ListaLibrosEditores  anterior: 
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biblioteca/views .py 


from  django. shortcuts  import  get_object_or_404 
from  django.views. generic  import  ListView 

from  biblioteca.models  import  Libro,  Editor 

class  ListalibrosEditores(ListView): 

template_name  = 'biblioteca/lista_libros_por_editores.htmr 

def  get_queryset(self): 

self.editor  = get_object_or_404(Editor,  nombre=self.args[G]) 
return  Libro. objects. filter(editor=self. editor) 


Como  puedes  ver,  es  sencillo  agregar  mas  logica  a la  selection  del  queryset,  en  este 
caso  filtrandolo;  si  quieres  puedes  usar  self.request.user  para  filtrar  usando  el  usuario 
actual  o realizar  otra  logica  mas  compleja. 

Tambien  puedes  agregar  un  editor  dentro  del  contexto,  asi  puedes  utilizarlo  en  la 
plantilla  al  mismo  tiempo: 

# ... 

def  get_context_data(self,  **kwargs): 

# Llama  primero  a la  implementation  para  traer  el  contexto 

context  = sup  (ListaLibrosEditores,  self).get_context_data(**kwargs) 

# Se  agrega  el  editor 

context['editor']  =self.  editor 

return  context 


Para  llamar  a esta  vista  en  la  plantilla  "editor_detail.html"  usa  la  siguiente  linea: 
<p><a  href="{%  url  iista-libros-editor'  editor. nombre  %}">Libros  publicados</a></p> 

Realizar  trabajo  extra 

El  ultimo  patron  comun  que  veremos  involucra  realizar  algun  trabajo  extra  antes  o 
despues  de  llamar  a la  vista  generica. 

Imagina  que  tenemos  un  campo  ultimo_acceso  en  nuestro  modelo  Autor  que 
usamos  para  tener  un  registro  de  la  ultima  vez  que  alguien  vio  ese  autor. 


biblioteca/models . py 


from  django. db  import  models 

class  Autor  (models.  Model): 

nombre  = models.  CharField(max_length=30) 

apellidos  = models.  CharField(max_length=40) 

email  = models. EmailField(blank=  , verbose_name='e-mail') 

ultimo_acceso  = models. DateTimeField(blank=True,  null=True) 

La  vista  generica  basada  en  la  clase  DetailView,  por  supuesto,  no  sabria  nada  sobre 
este  campo,  pero  una  vez  mas,  facilmente  podriamos  escribir  una  vista  personalizada 
para  mantener  ese  campo  actualizado. 

Primero,  necesitamos  agregar  una  pequena  parte  de  detalle  sobre  el  autor  en  la 
URLconf  para  que  apunte  a la  vista  personalizada: 
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urls .py 


from  django.conf.urls  import  url 

from  biblioteca. views  import  VistaDetallesAutor 

urlpatterns  = [ 

#... 

url(r'Aautores/(?P<pk>[0-9]+)/$',  VistaDetallesAutor. as_view(), 
name-detalles-autor'), 

] 


Nota:  La  URLconf  aqui  usa  un  nombre  de  grupo  pk  - este  nombre,  es  el  nombre 
predeterminado  que  DetailView  usa  para  encontrar  el  valor  de  una  clave  primaria 
que  se  usa  para  filtrar  el  queryset  (que  no  es  mas  que  la  clave  primaria  o primary 
key.) 

Si  quieres  llamar  esta  vista  con  otro  nombre  de  grupo,  puedes  fijarlo  a 
pk_url_kwarg  en  la  vista. 


Despues  escribimos  la  vista  - get_object  es  un  metodo  que  recupera  un  objeto, 
simplemente  sobreescribe  y envuelve  la  llamada. 


biblioteca/views .py 


from  django.views. generic  import  DetailView 
from  django. utils  import  timezone 

from  biblioteca.models  import  Autor 

class  VistaDetallesAutor(DetailView): 

queryset  = Autor. objects. all() 

def  get_object(self): 

# LLama  a la  superclase 

objeto  = supe  (VistaDetallesAutor,  self).get_object() 

# Graba  la  fecha  de  el  ultimo  acceso 

objeto.  ultimo_acceso  = timezone. now() 
objeto.  save() 

# Retorna  el  objeto 

return  objeto 


Introduccion  a los  mixins 


Los  mixins  son  una  forma  de  herencia  multiple,  donde  los  comportamientos  y los 
atributos  de  multiples  clases  padre,  pueden  heredarse  y combinarse  en  una  unica 
clase  hija. 

Por  ejemplo  en  las  vistas  genericas  basadas  en  clases  existe  un  mixin  llamado 
TemplateResponseMixin  cuyo  proposito  central  es  definir  el  metodo 
render_to_response().  Cuando  se  combina  con  el  comportamiento  de  la  clase  base 
View,  el  resultado  es  una  clase  TemplateView  que  enviara  peticiones  a los  metodos 
que  coincidan  con  la  petition  del  patron  (un  comportamiento  definido  en  la  clase 
base  View)  en  el  metodo  render_to_response()  y que  utiliza  un  atributo  como  el 
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nombre  de  una  plantilla  para  retornar  un  objeto  mediante  TemplateResponse  (un 
comportamiento  definido  en  el  mixin  TemplateResponseMixin.) 

Los  mixins  son  una  excelente  manera  de  reutilizar  el  codigo  a traves  de  multiples 
clases,  pero  vienen  con  un  cierto  costo.  Cuanto  mas  los  utilizas  mas  se  dispersa  el 
codigo,  lo  que  dificulta  leer  lo  que  hace  exactamente  una  clase  hija  y complica  aun 
mas  saber  que  metodos  remplazan  los  mixins  si  es  que  estas  usando  la  herencia  en 
subclases  con  una  cierta  profundidad. 

Observa  tambien  que  puedes  heredar  solamente  de  una  vista  generica  - es  decir, 
solo  una  clase  padre  puede  heredar  de  una  vista  y el  resto  (eventualmente)  deben  ser 
mixins.  Si  intentas  heredar  de  mas  de  una  clase  que  herede  de  View  - por  ejemplo, 
tratando  de  usar  un  formulario  en  la  cima  de  una  lista  y combinandola  con 
ProcessFormView  y ListView  - no  trabajara  segun  lo  esperado. 

Usando  un  mixin  en  vistas  genericas 

Veamos  ahora  como  usar  un  simple  mixin  llamado  SingleObjectMixin  que  se  encarga 
de  recuperar  un  solo  objeto,  con  una  vista  generica  ListView  que  como  vimos 
anteriormente  presenta  una  lista  de  objetos  de  un  determinado  modelo. 

La  vista  generica  ListView  ofrece  pagination  incorporada,  para  la  lista  de  objetos 
de  un  modelo,  usando  el  atributo  paginate_by,  pero  a lo  mejor  lo  que  quieres  paginar 
es  una  lista  de  objetos  que  estan  enlazados  (por  una  clave  foranea  por  ejemplo)  a otro 
objeto.  En  el  modelo  Editor  que  vimos  anteriormente,  para  paginar  una  lista  de  libros 
por  un  editor  en  especifico,  podriamos  hacerlo  de  la  siguiente  forma. 

Combinando  una  vista  ListView  con  un  mixin  SingleObjectMixin,  a fin  de  que  el 
queryset  para  la  lista  paginada  de  libros  cuelgue  de  un  simple  objeto  editor.  Para 
hacer  esto  necesitamos  primero  obtener  dos  querysets  diferentes: 

■ Libro:  queryset  para  usar  en  ListView. 

Puesto  que  tenemos  acceso  a la  lista  de  libros  de  un  editor  que  queremos 
listar,  podemos  simplemente  sobrescribir  el  metodo  get_queryset  ()  y utilizar 
el  manejador  para  usar  los  editores  del  campo  foraneo  Libro  en  relation 
inversa. 

■ Editores:  un  queryset  para  usar  con  get_object(). 

Confiaremos  en  la  implementation  predeterminada  del  metodo  get_object() 
para  traer  el  objeto  correcto  Editor.  Sin  embargo,  necesitamos  explicitamente 
pasarle  un  argumento  al  queryset  porque  de  otra  manera  la  implementation 
predeterminada  de  get_object()  llamara  al  metodo  get_queryset()  el  cual 
sobrescribira  los  objetos  Libro  devueltos  en  lugar  de  el  Editor. 


Con  esto  en  mente,  ahora  podemos  escribir  la  vista: 


biblioteca/views .py 


from  django. views. generic  import  ListView 

from  django.views. generic. detail  import  SingleObjectMixin 

from  biblioteca.models  import  Editor 

class  DetalleEditores(SingleObjectMixin,  ListView): 
paginate_by  = 3 

template_name  = "biblioteca/detalles_editores.html" 
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def  get(self,  request,  *args,  **kwargs): 

self.object  = self. get_object(queryset=Editor. objects. all()) 
return  sup  (DetalleEditores,  self).get(request,  *args,  **kwargs) 

def  get_context_data(self,  **kwargs): 

context  = supt  (DetalleEditores,  self).get_context_data(**kwargs) 
context['editor']  = self.object 
return  context 

def  get_queryset(self): 

return  self. object. libro_set.all() 

Ffjate  como  colocamos  self.object  dentro  del  metodo  get()  para  usarlo  mas 
adelante  dentro  del  metodo  get_context_data()  y obtener  un  metodo  get_queryset(). 
Si  no  usamos  el  atributo  template_name  para  configurar  el  nombre  de  la  plantilla, 
Django  usara  el  valor  por  defecto  para  ListView  la  cual  en  este  caso  es 
“biblioteca/libro_list.html”  porque  es  una  lista  de  libros;  ListView  no  sabe  nada 
acerca  de  el  mixin  SingleObjectMixin,  asi  que  no  tiene  ninguna  pista  sobre  que  esta 
vista  es  una  lista  de  libros  de  acuerdo  a un  editor  predeterminado. 

Observa  que  el  atributo  paginate_by  es  deliberadamente  pequeno  en  este 
ejemplo,  para  que  no  tengas  que  crear  un  buen  lote  de  libros  para  ver  en 
funcionamiento  la  pagination. 

Esta  es  la  plantilla  que  usa: 


biblioteca/templates/biblioteca/  detalles_edi tores  .html 


{%  extends  "base.html"  %} 

{%  block  content  %} 

<h2>Editor  {{  editor. nombre  }}</h2> 

<ol> 

{%  for  libro  in  page_obj  %} 

<li>{{  libro. titulo  }}</li> 

{%  endfor  %} 

</ol> 

<div  class="pagination"> 

<span  class="step-links"> 

{%  if  page_obj.has_previous  %} 

<a  href="?page={{  page_obj.previous_page_number  }}">anterior</a> 
{%  end  if  %} 

<span  class="current"> 

Pagina  {{  page_obj. number }}  de  {{  paginator.num_pages  }}. 

</span> 

{%  if  page_obj.has_next  %} 

<a  href="?page={{  page_obj.next_page_number  }}">siguiente</a> 

{%  end  if  %} 

</span> 

</div> 

{%  endblock  %} 


Esta  es  la  url  que  puedes  usar  para  llamar  la  vista: 
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urls .py 


from  django.conf.urls  import  url 

from  biblioteca. views  import  DetalleEditores 

urlpatterns  = [ 

#... 

url(r'Adetalle/editores/(?P<pk>[0-9]+)/$',  DetalleEditores. as_view(), 
name-detalle-editores' ), 

] 


Y se  puede  llamar  con  la  clave  primaria  de  un  editor,  en  una  plantilla  de  detalles  : 
<p><a  href="{%  url  'detalle-editores'  editor. pk  %}">Editores</a></p> 

El  uso  de  mixins  y vistas  genericas  es  una  buena  forma  de  extender  las  vistas 
basadas  en  clases,  en  el  ejemplo  anterior  observamos  en  action  un  simple  mixins 
llamado  SingleObjectMixin  que  se  encarga  de  traer  un  objeto,  sin  embargo  Django 
cuenta  con  una  conveniente  cantidad  de  mixins  repartidos  en  las  siguientes 
categorias,  que  se  explican  a si  mismos: 

■ Simple  mixins 

■ Single  object  mixins 

■ Multiple  object  mixins 

■ Editing  mixins 

■ Date-based  mixins 


Envolviendo  el  metodo  as_view()  con  mixins 

Una  forma  de  aplicar  un  comportamiento  comun  a muchas  clases  es  escribir  un 
mixin  que  envuelva  el  metodo  as_view ()■ 

Por  ejemplo,  si  tienes  muchas  vistas  genericas  que  necesites  decorar  con  un 
metodo  /ogin_ required  ()  lo  podrias  implementar  usando  un  mixin  como  este: 

from  django.contrib.auth. decorators  import  login_required 

class  RequiereLogin(object): 

@classmethod 

def  as_view(cls,  **initkwargs): 

vista  = supe  (RequiereLogin,  cls).as_view(**initkwargs) 
return  login_required(vista) 

class  MiVista(RequiereLogin,  ...): 

# Esta  es  la  vista  generica 


239 


CAPITULO  1 1 VISTAS  GENERICAS 


Manejando  formularios  con  vistas  basadas  en  clases  genericas 

Una  vista  basada  en  una  funcion  que  maneja  un  formulario,  luce  asi: 

from  django.http  import  HttpResponseRedirect 
from  django. shortcuts  import  render 

from  .forms  import  MyForm 

def  mivista(request): 

if  request. method  ==  "POST": 
form  = MyForm(request.POST) 
if  form.is_valid(): 

# <proceso  el  formulario  con  cleaned  data> 

return  FlttpResponseRedirectC/success/') 

else: 

form  = MyForm(initial={'key':  'value'}) 
return  render(request,  'formulario. html',  {'form':  form}) 


De  igual  forma  una  vista  basada  en  una  clase  base,  se  ve  asi: 

from  django.http  import  PlttpResponseRedirect 
from  django. shortcuts  import  render 
from  django.views. generic  import  View 

from  .forms  import  MyForm 

class  MiFormulario(View): 

form_class  = MyForm 
initial  = {'key':  'value'} 
template_name  = 'formulario. html' 

def  get(self,  request,  *args,  **kwargs): 
form  = self.form_class(initial=self.initial) 
return  render(request,  >lf.template_name,  {'form':  form}) 

def  post(self,  request,  *args,  **kwargs): 
form  = self.form_class(request.POST) 
if  form.is_valid(): 

# <proceso  el  formulario  con  cleaned  data> 

return  HttpResponseRedirect('/success/') 

return  render(request,  5elf.template_name,  {'form':  form}) 


Como  puedes  observar,  este  es  un  caso  muy  simple  del  uso  de  clases  genericas 
para  el  manejo  de  formularios,  pero  te  daras  cuenta  enseguida  de  las  ventajas  de  usar 
este  enfoque  basado  en  clases,  ya  que  tendrias  la  option  de  modificar  esta  vista  para 
requisitos  particulares,  personalizando  y sobrescribiendo  los  atributos  de  la  vista,  por 
ejemplo  form_class,  template_name  a traves  de  la  configuration  de  la  URLconf,  o de 
una  subclase  y tambien  podrias  reemplazar  uno  o mas  metodos  (jo  todos!). 
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Ejemplo  de  un  formulario  usando  una  clase  generica 

Como  se  menciona  anteriormente  las  vistas  genericas  de  Django  brillan  realmente 
cuando  se  necesitan  presentar  datos,  sin  embargo  tambien  brillan  cuando  es 
necesario  guardar  y procesar  datos  mediante  formularios  Web. 

A1  trabajar  con  modelos  podemos  crear  automaticamente  formularios  a partir  de 
un  modelo,  usando  vistas  genericas  basadas  en  clases  (en  el  capitulo  8 vimos  un 
ejemplo). 

Esta  es  la  forma  en  que  las  puedes  utilizar: 

■ Si  se  da  el  atributo  de  un  modelo,  ese  modelo  de  clase  sera  utilizada. 

■ Si  get_object  ()  devuelve  un  objeto,  la  clase  de  ese  objeto  sera  utilizada. 

■ Si  se  da  un  queryset,  el  modelo  para  ese  queryset  sera  utilizado. 

Las  vistas  para  los  modelos  de  un  formulario  proveen  un  metodo  form_valid  que 
sobrescribe  el  modelo  automaticamente.  Puedes  reemplazar  esto  si  necesitas  algun 
requisito  en  especial. 

No  necesitas  proveer  un  metodo  success_url  para  una  vista  tipo  CreateView  o 
UpdateView  ya  que  usan  el  metodo  get_absolute_url()  de  el  modelo,  si  este  esta 
disponible. 

Si  quieres  usar  un  formulario  personalizado  con  la  clase  ModelForm  (como  una 
instancia  para  agregar  validation)  simplemente  fija  el  valor  form_class  en  la  vista. 


Nota:  Cuando  especifiques  una  clase  de  un  formulario  personalizada,  es 
necesario  especificar  el  modelo  usando  una  clase  de  ModelForm. 


Para  ver  las  clase  genericas  en  action,  lo  primero  que  vamos  hacer  es  agregar  un 
metodo  get_absolute_url()  a la  clase  Autor  del  modelo,  para  asi  usarlo  como 
redirecionamiento  por  defecto: 


biblioteca/models . py 


from  django.db  import  models 

from  django.core.urlresolvers  import  reverse 

class  Autor(models. Model): 

nombre  = models.  CharField(max_length=30) 

# Omitimos  los  demas  campos  y metodos. 

def  get_absolute_url(self): 

return  reverse(  detalles-autor',  kwargs={'pk':  self.pk}) 

Ahora  podemos  llamar  a la  clase  CreateView  y a sus  amigos  para  que  hagan  el 
trabajo  duro. 

Observa  que  lo  unico  que  necesitamos  es  configurar  las  vistas  genericas  basadas 
en  clases-base  aqui;  no  tenemos  que  escribir  ninguna  logica  nosotros  mismos,  sin 
embargo  por  convention  agregamos  los  formularios  en  una  vista  especial  llamada 
por  convention  forms. py,  en  el  mismo  nivel  que  models.py : 
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biblioteca/forms .py 


from  django. views. generic. edit  import  CreateView,  UpdateView,  DeleteView 
from  django. core. urlresolvers  import  reversejazy 

from  biblioteca.models  import  Autor 

class  CrearAutor(CreateView): 

model  = Autor 

fields  = ['nombre',  'apellidos',  'email',] 

class  ActualizarAutor(UpdateView): 

model  = Autor 

fields  = ['nombre',  'apellidos',  'email',] 

class  BorrarAutor(DeleteView): 

model  = Autor 

success_url  = reversejazy('lista-autor') 


Nota:  Observa  que  usamos  el  metodo  reverse_lazy()  en  la  ultima  clase,  el  cual  es 
util  para  cuando  se  necesita  utilizar  una  url  inversa,  antes  de  que  se  cargue  la 
URLConf  de  el  proyecto. 

El  atributo  fields  trabaja  de  la  misma  forma  que  un  atributo  fields  en  una  clase 
interna  Meta  dentro  de  una  clase  ModelForm.  A menos  que  definas  un  formulario  de 
otra  forma  el  atributo  es  requerido  y la  vista  lanzara  una  exception  del  tipo 
ImproperlyConfigured  si  no  lo  encuentra. 


Finalmente  enlazamos  las  nuevas  vistas  basadas  en  clases  para  Crear,  Actualizar  y 
Borrar  objetos,  (CRUD  por  sus  siglas  en  ingles:  Create,  Update  y Delete)  en  la 
URLconf: 


urls .py 


from  django. conf.urls  import  url 

from  biblioteca.forms  import  CrearAutor,  ActualizarAutor,  Borrar  Autor 

urlpatterns  = [ 

# ... 

url(r'autor/agregar/$',  CrearAutor.as_view(),  name- agregar-autor'), 
url(r'autor/(?P<pk>[0-9]+)/$',  ActualizarAutor. as_view(),  name-actualizar-autor'), 
url(r'autor/(?P<pk>[0-9]+)/borrar/$',  BorrarAutor.as_view(),  name-borrar-autor'), 

] 


Esta  vistas  heredan  del  mixin  SingleObjectTemplateResponseMixin  el  cual  usa  el 
metodo  template_name_suffix  para  construir  el  nombre  de  la  plantilla  con  el  atributo 
template_name  basado  en  el  nombre  del  modelo. 

En  este  ejemplo: 

■ CreateView  y UpdateView  usan  la  misma  plantilla: 
“biblioteca/autor_form.html” 

■ DeleteView  usa  la  plantilla  “biblioteca/ autor_confirm_delete.html” 
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Si  quieres  especificar  nombres  diferentes  para  cada  plantilla  de  la  clase 
CreateView  y UpdateView,  puedes  configurarlos  mediante  el  atributo 
"template_name"  como  en  cualquier  vista  basada  en  clases. 


biblioteca/autor  form.html 


<html> 

<head> 

<title>Agregar  autor</title> 

</head> 

<body> 

<hl>Agregar  autor</hl> 

{%  if  form. errors  %} 

<p  style="color:  red;"> 

Por  favor  corrige  lo  siguiente: 

</p> 

{%  endif  %} 

<form  action-"'  method="post">{%  csrf_token  %} 

<div  class="field"> 

{{ form. nombre. errors  }} 

<label  for="id_nombre">Nombre:</label> 

{{ form. nombre }} 

</div> 

<div  class="field"> 

{{ form. apellidos. errors  }} 

<label  for="id_apellidos">Apellidos:</label> 

{{ form. apellidos }} 

</div> 

<div  class="field"> 

{{ form. email. errors  }} 

<label  for="id_email">E-mail:</label> 

{{ form. email }} 

</div> 

<input  type="submit"  value="Enviar"> 

</form> 

</body> 

</html> 

Como  practica,  crea  la  plantilla  faltante. 

Si  sigues  los  ejemplos  interactivamente,  en  este  punto  de  puedes  preguntar  jComo 
protejo  mis  vistas  para  que  solo  usuarios  autentificados  puedan  acceder  a ellas,  ya 
que  seria  bastante  "descuidado"  que  cualquiera  pudiera  crear  borrar  o actualizar 
objetos  de  la  base  de  datos,  sin  autorizacion  ? La  respuesta  es  usando  decoradores,  ya 
sea  en  la  vista  misma  o en  la  URLconf. 

Django  te  provee  de  algunos  atajos  dedicados  especialmente  a cubrir  estas 
necesidades,  puedes  usar:  login_required  o permission_required.  Porque  estos  temas 
son  una  necesidad  muy  comun  veamos  su  uso. 
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Decorando  vistas  de  una  clase-base 

La  extension  de  vistas  basadas  en  clases  no  se  limita  a usar  solamente  mixins. 
Tambien  puedes  utilizar  decoradores.  Puesto  que  las  vistas  basadas  en  clases  no  son 
funciones,  necesitas  decorarlas  de  forma  diferente  dependiendo  de  si  estas  utilizando 
el  metodo  as_view  o esta  creando  una  subclase  de  una  clase. 


Decorando  vistas  de  una  clase-base 

La  forma  mas  simple  de  decorar  una  vista  basada  en  una  clase,  es  decorar  el 
resultado  de  el  metodo  as_view().  El  lugar  mas  sencillo  para  hacer  esto  es  en  la 
URLconf  donde  se  despliega  la  vista: 

from  django.contrib.auth. decorators  import  login_required 
from  django. views. generic  import  TemplateView 

from  biblioteca.forms  import  CrearAutor 

urlpatterns  = [ 

# 

url(r'agregar/autor/$',  permission_required(CrearAutor.as_view()), 
name-agregar-autor'), 

] 


Esta  aproximacion  aplica  unicamente  a decoradores  por-instancia.  Si  quieres  que 
cada  instancia  de  una  vista  sea  decorada,  necesitas  usar  un  acercamiento  diferente 

Decorando  una  clase 

Para  decorar  cada  instancia  de  una  vista  basada  en  clases,  necesitas  decorar  la 
definition  de  la  clase  misma.  Para  hacer  esto  aplica  el  decorador  a el  metodo 
dispatch  ()  de  la  clase. 

Un  metodo  sobre  una  clase  no  equivale  realmente  a una  funcion  independiente, 
asi  que  solo  puedes  aplicar  un  decorador  a un  metodo  de  una  funcion  — por  lo  que 
necesitas  transformarlo  en  un  decorador  primero.  El  decorador  @method_decorator 
transforma  un  decorador  de  una  funcion  en  un  decorador  de  un  metodo  a fin  de  que 
puede  ser  usado  sobre  una  instancia  de  un  metodo.  Por  ejemplo: 

from  django.contrib.auth. decorators  import  login_required 
from  django. utils. decorators  import  method_decorator 

from  django. views. generic  import  TemplateView 

class  Vista  Protegida(TemplateView): 
template_name  = 'pagina-secreta.html' 

@method_decorator(login_required) 
def  dispatch(self,  *args,  **kwargs): 

returns  (Vista  Protegida,  f).dispatch(*args,  **kwargs) 


En  este  ejemplo,  cada  instancia  de  Vista  Protegida,  tendra  protection  de  login. 
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Nota:  El  method_decorator  pasa  *args  y **kwargs  como  parametros  al  metodo 
del  decorador  de  la  clase.  Si  el  metodo  no  valida  el  conjunto  de  parametros 
compatibles  levantara  una  exception  del  tipo  TypeError. 


Soporte  para  Apis 

Supongamos  que  alguien  quiere  acceder  a nuestra  biblioteca  de  libros  sobre  HTTP, 
usando  la  vista  como  una  API.  La  API  del  cliente  se  conectaria  de  vez  en  cuando  y 
descarga  la  lista  de  libros  publicados  desde  su  ultima  visita.  Pero  si  no  se  ha 
publicado  ningun  libro  desde  la  ultima  vez,  seria  una  perdida  de  CPU  y de  ancho  de 
banda  obtener  todos  los  libros  de  la  base  de  datos,  renderizar  una  respuesta 
completa  y enviarsela  al  cliente.  No  seria  preferible  preguntarle  a la  API  cuales  son  los 
libros  recientemente  publicados. 

Para  hacer  este  trabajo,  mapeamos  la  URL  a la  vista  que  obtendra  la  lista  de  libros: 

from  django.conf.urls  import  url 

from  biblioteca. views  import  VistaLibrosRecientes 

urlpatterns  = [ 

url(r'Alibros/$’,  VistaLibrosRecientes. as_view(),  name  = 'ultimos-libros'), 

] 


Y creamos  la  clase  para  la  vista: 

from  django.http  import  HttpResponse 
from  django. views. generic  import  ListView 

from  biblioteca.models  import  Libro 

class  VistaLibrosRecientes(ListView): 

model  = Libro 

template_name  = 'ultimosjibros.html' 

def  head(self,  *args,  **kwargs): 

ultimosjibros  = elf.get_queryset().latest('fecha_publicaciori) 
response  = HttpResponse( ") 

# Formato  de  datos  RFC  1123 

response['modificados']  = ultimosjibros.  fecha_publicacion.strftime( 

'%a,  %d  %b  %Y  %H:%M:%S  GMT’) 
return  response 


Si  la  vista  es  accesada  por  una  peticion  GET  una  simple  lista  de  objetos  sera 
devuelta  como  respuesta  (usando  la  plantilla  “ultimosjibros.html”)  Pero  si  el  cliente 
nos  envra  una  peticion  HEAD,  la  respuesta  tendra  un  cuerpo  vacio  y la  cabecera  de  la 
ultima  modification  indicara  los  libros  que  se  publicaron  recientemente.  Basados  en 
esta  information,  el  cliente  puede  o no  descargar  la  lista  completa  de  objetos. 
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<?,Que  sigue? 

En  este  capitulo  hemos  examinado  solo  un  par  de  las  vistas  genericas  que  incluye 
Django,  pero  las  ideas  generales  presentadas  aqui  deberian  aplicarse  a cualquier  vista 
generica  basada  en  clases.  El  Apendice  C cubre  todas  las  vistas  disponibles  en  detalle, 
y es  de  lectura  obligada  si  quieres  sacar  el  maximo  provecho  a esta  poderosa 
caracteristica  de  Django. 

Aqui  concluye  la  seccion  del  libro  dedicada  al  “uso  avanzado  de  Django”.  En  el 
proximo  capitulo  cubriremos  el  despliegue  de  aplicaciones  en  Django. 


CAPITULO  12 


Desplegando  Django 


Este  capitulo  cubre  el  ultimo  paso  esencial  para  construir  una  aplicacion  Django: 
eldespliegue  en  un  servidor  de  production. 

Si  has  estado  siguiendo  los  ejemplos  presentados,  probablemente  has  estado  usando 
runserver,  como  ya  sabes  este  comando  inicia  el  servidor  web  y hace  que  las  cosas 
sean  realmente  muy  faciles  - con  runserver,  no  tienes  que  preocuparte  por  instalar 
un  servidor  Web. 

Sin  embargo  runserver  esta  disenado  unicamente  para  ser  usado  en  la  etapa  de 
desarrollo  de  forma  local,  no  para  exponerlo  en  un  sitio  publico  Web.  Para  desplegar 
una  aplicacion  Django,  es  necesario  utilizar  un  servidor  Web  poderoso  tal  como 
Apache.  En  este  capitulo  te  mostraremos  como  hacerlo  - pero  primero,  es  necesario 
comprobar  una  lista  de  cosas  que  hacer  en  el  codigo  antes  de  llevarlo  a un  entorno  de 
production. 

Prepara  tu  codigo  base  para  produccion 

Afortunadamente  el  comando  runserver  es  bastante  parecido  a un  servidor  “real”, 
por  lo  que  no  necesitas  realizar  muchos  cambios  a tu  aplicacion  Django  para  dejarla 
lista  para  produccion.  Sin  embargo  hay  algunas  cosas  esenciales  que  necesitas 
conocer  antes  de  servirla  en  produccion. 

Desactiva  el  Modo  Debug 

Cuando  creamos  un  proyecto  en  el  capitulo  2,  el  comando  django-admin.py 
startproject  creo  un  archivo  llamado  settings.py  el  cual  contiene  la  variable  DEBUG 
fijada  en  True  por  defecto,  es  decir  que  esta  en  modo  de  depuration.  Muchas  de  las 
partes  internas  de  Django  comprueban  esta  configuration  y cambian  su 
comportamiento  si  el  modo  DEBUG  esta  activado.  Por  ejemplo,  si  DEBUG  esta  fljado 
en  True,  entonces: 

Todas  las  consultas  a la  base  de  datos  se  guardan  en  memoria  como  objetos 
django.db.connection.queries.  Como  puedes  imaginar,  jesto  consume  mucha 
memoria! 

Cualquier  error  404,  renderizara  una  pagina  especial,  a decir  una  pagina  no 
encontrada  (cubierta  en  el  capitulo  3)  mas  que  retornar  una  apropiada  respuesta  404. 
Esta  pagina  contiene  information  potencialmente  sensible  y no  debe  ser  expuesta  al 
publico  en  Internet. 

Cualquier  exception  no  atrapada  en  tu  aplicacion  Django  - desde  errores  basicos 
en  la  sintaxis  Python,  errores  de  la  base  de  datos  o en  la  sintaxis  de  la  plantilla  - seran 
renderizados  por  las  paginas  de  errores  bonitas  de  Django  que  probablemente 
adoras.  Esta  pagina  contiene  mas  information  sensible  incluso  que  las  paginas  404, 
por  lo  que  nunca  deben  ser  expuestas  al  publico. 

Resumiendo,  la  variable  de  configuration  DEBUG  = True  le  dice  a Django  que 
asuma  que  unicamente  desarrolladores  confiables  estan  usando  el  sitio.  La  internet 
esta  llena  de  personas  poco  fiables,  y la  primera  cosa  que  debes  hacer  cuando  estes 
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preparando  tu  aplicacion  para  el  despliegue  en  production  es  Ajar  la  variable  DEBUG 
a False. 


Desactiva  el  Modo  Debug  en  las  plantillas 

De  igual  forma,  es  necesario  fijar  la  variable  TEMPLATE_DEBUG  a False  en 
produccion.  Esto  para  desactivar  el  modo  depuration  de  las  plantillas.  Ya  que  si  esta 
fijada  en  True,  esta  configuration  le  dice  al  sistema  de  plantillas  de  Django  que 
guarde  information  extra  acerca  de  cada  plantilla,  para  mostrarla  en  las  utiles 
paginas  de  error,  si  el  modo  DEBUG  = True  (esta  activado). 

Implementa  una  plantilla  404 

Si  DEBUG  es  True,  Django  mostrara  una  muy  util  pagina  de  error  404.  Pero  si  DEBUG 
es  False,  hara  algo  completamente  diferente:  renderizara  una  plantilla  llamada 
404.html  en  la  raiz  del  directorio  de  plantillas.  Entonces,  cuando  estas  listo  para  el 
despliegue,  necesitas  crear  esta  plantilla  y ponerle  algo  util,  como  un  mensaje  de 
“Pagina  no  encontrada”. 

Aqui  esta  un  ejemplo  de  una  pagina  404.html,  puedes  usarla  como  el  punto  de 
partida,  para  crear  tu  propia  plantilla.  La  plantilla  asume  que  estas  usando  la 
herencia  de  plantillas  y tiene  definida  una  plantilla  base.html  con  bloques  llamados 
titulo  y contenido. 


404 . html 


{%  extends  "base.html"  %} 

{%  block  title  %}Pagina  no  encontrada  {%  endblock  %} 

{%  block  content  %} 

<hl>Pagina  no  encontrada</hl> 

<p>Lo  sentimos,  pero  la  pagina  que  buscas  no  ha  sido  encontrada. </p> 

{%  endblock  %} 

Para  probar  que  la  plantilla  404.html  funciona,  solo  cambia  el  modo  DEBUG  a 
False  y visita  una  URL  que  no  exista.  (Esto  trabaja  de  igual  forma  en  el  servidor  de 
desarrollo  con  runserver,  que  en  un  servidor  de  produccion.) 

Implementa  una  plantilla  500 

De  igual  forma  si  DEBUG  es  False,  Django  no  mostrara  la  util  pagina  de  traza  de 
errores,  en  caso  de  excepciones  no  manejadas.  En  su  lugar  mostrara  y renderizara 
una  plantilla  llamada  500.html.  Tal  como  la  pagina  404.html,  esta  plantilla  debe  de 
localizarse  en  la  raiz  del  directorio  de  plantillas. 

Hay  una  ligera  trampa  acerca  de  las  paginas  500.html.  Nunca  puedes  estar  seguro 
por  que  se  renderiza  esta  plantilla,  asi  que  no  deberias  hacer  nada  que  requiere  una 
conexion  a la  base  de  datos  o confiar  en  cualquier  parte  potencialmente  rota  de  tu 
infraestructura.  (Por  ejemplo,  no  deberias  usar  etiquetas  personalizadas  en  la 
plantillas  500.)  Si  usas  la  herencia  de  plantillas,  entonces  la  plantilla  padre,  no  deberia 
poder  conectarse  a la  infraestructura  potencialmente  rota.  Por  consiguiente,  la  mejor 
forma  de  aprovechar  esto,  es  evitar  la  herencia  de  plantillas  y usar  algo  muy  simple  y 
solo  en  HTML.  Aqui  hay  un  ejemplo  de  una  pagina  500.html,  como  un  punto  de 
partida,  para  que  disenes  la  tuya: 
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500 . html 


<!DOCTYPE  html  PUBLIC  "-//W3C//DTD  HTML  4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd"> 

<html  lang="en"> 

<head> 

<title>Pagina  no  disponible</title> 

</head> 

<body> 

<hl>Pagina  no  disponible</hl> 

<p>Lo  sentimos,  pero  la  pagina  pedida  no  esta  disponible  por  que 
el  servidor  tiene  hipo.</p> 

<p>Los  desarrolladores  han  sido  notificados,  asi  que  vuelva  a revisar  mas 
tarde</p> 

</body> 

</html> 


Establece  errores  de  alerta 

Cuando  tu  sitio  creado  con  Django  esta  corriendo  y se  lanza  una  excepcion,  necesitas 
estar  al  tanto,  para  poder  corregir  cualquier  defecto.  Por  omision,  Django  esta 
configurado  para  enviar  un  e-mail  a los  desarrolladores  del  sitio,  cuando  el  codigo 
lanza  una  excepcion;  pero  necesitas  hacer  algunas  cosas  para  configurarlo. 

■ Primero  cambia  la  configuracion  ADMINS  para  incluir  la  direction  de  e- 
mail,  con  las  direcciones  de  cada  una  de  las  personas  que  necesitan  ser 
notificadas.  Esta  configuracion  es  una  tupla  del  tipo  (no  mb  re,  email),  la 
tupla  puede  ser  asi: 

ADMINS  = ( 

(’John  Lennon’,  ’jlennon@example.com’), 

(’Paul  McCartney’,  ’pmacca@example.com’), 

) 

■ Segundo,  asegurate  de  que  tu  servidor  este  configurado  para  enviar  e- 

mails.  Configurar  postfix,  sendmail  o cualquier  otro  servidor  de  e-mails, 
esta  fuera  del  alcance  de  este  libro,  pero  del  lado  de  Django,  debes  de 
asegurarte  de  configurar  EMAIL_HOST  y establecer  el  “hostname” 
apropiado  para  tu  servidor  de  correo.  Si  lo  estableces  a 'localhost'  por 
defecto,  trabajara  fuera  de  la  caja  en  muchos  entornos  de  servicios 
compartidos.  Tambien  es  necesario  que  establezcas  los  parametros  de  las 
siguientes  configuraciones:  EMAIL_HOST_USER, 

EMAIL_HOST_PASSWORD,  EMAIL_PORT  o EMAIL_USE_TLS, 
dependiendo  de  la  complejidad  de  tu  infraestructura. 

■ Por  ultimo,  tambien  establece  el  prefijo  con  EMAIL_SUBJECT_PREFIX  el 
cual  controla  el  nombre  que  Django  usa  delante  de  los  errores  en  los 
correos  electronicos.  Por  defecto  esta  establecido  en  ' [Django] 
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Establece  alertas  para  enlaces  rotos 

Si  tienes  la  clase  CommonMiddleware  instalada  (en  tu  archivo  de  configuration  en  la 
variable  MIDDLEWARE_CLASSES  que  incluye 

'django. middleware. common.CommonMiddleware',  lo  cual  ocurre  por  defecto) 
tienes  la  option  de  recibir  un  e-mail  cada  vez  que  alguien  visita  una  pagina  creada 
con  Django  que  lanze  un  error  404  con  una  referencia  a no-vacia  - esto  es  cada  vez 
que  encuentre  enlaces  rotos.  Si  quieres  activar  esta  caracteristica,  establece 
SEND_BROKEN_LINK_EMAILS  a True  (esta  es  False  por  defecto)  y establece  en  la 
configuration  MANAGERS  a la  persona  o personas  que  recibiran  esos  e-mails  de 
enlaces  rotos.  MANAGERS  usa  la  misma  sintaxis  que  ADMINS,  un  tupla.  Por  ejemplo: 

MANAGERS  = ( 

(’George  Harrison’,  ’gharrison@example.com’), 

(’Ringo  Starr’,  ’ringo@example.com’), 

) 


Observa  que  los  e-mails  de  errores  pueden  llegar  a ser  muy  molestos;  no  son  para 
todo  el  mundo. 

Como  usar  diferentes  configuraciones  para  produccion 

Elasta  ahora  en  este  libro,  hemos  tratado  unicamente  con  un  simple  archivo  de 
configuraciones  s ellings.py  generado  por  el  comando  django- admin. py  startproject. 
Pero  como  estamos  listos  para  desplegarlo,  probablemente  nos  encontremos  con  la 
necesidad  de  usar  multiples  archivos  de  configuraciones  para  mantener  el  entorno  de 
desarrollo  aislado  del  ambiente  de  produccion. 

Por  ejemplo,  probablemente  no  quieras  cambiar  DEBUG  de  False  a True  cada  vez 
que  quieras  probar  los  cambios  al  codigo,  en  tu  maquina  de  forma  local.  Django  hace 
esto  muy  sencillo,  permitiendote  usar  multiples  archivos  de  configuraciones. 

Si  quieres  organizar  tus  archivos  de  configuraciones,  dividiendolos  en  “desarrollo” 
y “produccion”,  puedes  lograrlo  usando  una  de  las  siguientes  tres  formas. 

■ Establece  dos  archivos  de  configuraciones  completos,  de  forma 
independiente. 

■ Establece  un  archivo  de  configuraciones  “base”  (uno  para  desarrollo)  y un 
segundo  (para  produccion)  el  archivo  de  configuraciones  simplemente 
importa  del  primero  y define  lo  que  necesita  y lo  que  debe  sobrescribirse. 

■ Usa  unicamente  un  archivo  de  configuraciones  y deja  que  Python  se  encargue 
de  la  logica  y haga  los  cambios  a las  configuraciones,  basado  en  el  contexto. 

Veamos  estas  tres  opciones,  una  por  una. 

Primero,  la  forma  mas  basica  para  aprovechar  esto,  es  definir  dos  archivos 
separados.  Si  estas  siguiendo  esto,  ya  tienes  un  archivo  settings.py.  Ahora  solo  es 
necesario  realizar  una  copia  llamada  settings_production.py.(  Si  no  te  gusta  el 
nombre,  puedes  llamarlo  como  quieras)  En  este  nuevo  archivo,  cambia  las  variables 
necesarias  como  DEBUG,  etc. 

La  segunda  forma  de  aprovechar  esto  es  muy  parecida,  pero  reduce  algo  de 
redundancia,  En  lugar  de  tener  dos  archivos  de  configuraciones  con  contenido 
similar,  tratamos  solo  con  un  archivo  “base”  y creamos  otro  archivo  que  lo  importe. 
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Por  ejemplo: 

# settings. py 
DEBUG  = True 

TEMPLATE_DEBUG  = DEBUG 
DATABASE_ENGINE  = ’postgresql_psycopg2’ 
DATABASE_NAME  = ’devdb’ 
DATABASE_USER  = ” 

DATABASE_P  AS  SWORD  = ” 
DATABASE_PORT  = ” 

# ... 

# settings_produccion.py 
from  settings  import  * 

DEBUG  = TEMPLATE_DEBUG  = False 
DATABASE_NAME  = ’production’ 
DATABASE_USER  = ’app’ 

DATABASE_P  AS  SWORD  = ’dejameentrar’ 


Aqul  tenemos  que  settings_production.py  importa  cualquier  cosa  de  settings.py  y 
solo  redefine  las  configuraciones  que  son  usadas  especialmente  en  production.  En 
este  caso  DEBUG  esta  fijado  en  False,  pero  tambien  hemos  fijado  diversos 
parametros,  como  el  acceso  a la  base  de  datos  para  configurarla  en  production.  (Mas 
adelante  te  mostraremos  como  redefinir  cualquier  configuration,  no  unicamente  las 
basicas  como  DEBUG.) 

Finalmente,  la  forma  mas  concisa  para  lograr  tener  dos  entornos  de 
configuraciones  es  usar  un  solo  archivo,  que  se  ramifique  basado  en  el  entorno.  Una 
de  las  formas  de  lograr  esto  es  comprobar  el  actual  “hostname.”  Por  ejemplo: 

# settings.py 
import  socket 

if  socket. gethostnameO  ==  ’my-laptop’: 

DEBUG  = TEMPLATE_DEBUG  = True 

else: 

DEBUG  = TEMPLATE_DEBUG  = :alse 

# ... 

Aqul,  importamos  el  modulo  socket  de  la  librerfa  estandar  de  Python  y lo  usamos 
para  comprobar  el  nombre  actual  del  sistema.  Podemos  comprobar  el  “nombre”  para 
determinar  si  el  codigo  esta  siendo  ejecutado  en  un  servidor  de  production. 

La  lection  central,  es  que  el  archivo  de  configuraciones  es  solo  codigo  Python.  Que 
puede  importar  otros  archivos,  puede  ejecutar  logica  arbitraria,  etc.  Solo  asegurate  de 
que  el  codigo  Python  en  tu  archivo  de  configuraciones  sea  a prueba  de  balas.  Si  lanza 
una  exception,  Django  probablemente  se  estrellara  de  fea  manera. 


RENOMBRAR  settings.py 


Sientete  libre  de  renombrar  tu  archivo  settings.py  a settings_dev.py  o settings /dev.py 
o foobar.py  - A Django  no  le  importa  como  lo  llames,  solo  necesita  saber  que  archivo 
estas  usando  para  usarlo  como  configuration. 

Solo  ten  en  cuenta  que  si  renombras  el  archivo  settings.py  que  es  generado  por  el 
comando  django-admin.py  startproject,  te  encontraras  con  que  manage.py  lanza  un 
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mensaje  de  error,  diciendo  que  no  puede  encontrar  el  archivo  de  configuraciones. 
Esto  es  debido  a que  trata  de  importar  un  modulo  llamado  settings.  Puedes  arreglar 
esto  editando  manage.py  y cambiandole  el  nombre  de  settings  por  el  nombre  de  tu 
modulo  o usando  django-admin.py  en  lugar  de  manage.py.  En  este  ultimo  caso, 
necesitas  fijar  DJANGO_SETTINGS_MODULE  con  las  variables  de  entorno  de  la  ruta 
de  busqueda  Python  en  tu  archivo  de  configuraciones  (por  ejemplo  'misitio. settings') 
Cuando  usas  Django  tienes  que  indicarle  que  configuration  estas  usando.  Elaz 
esto  mediante  el  uso  de  de  la  variable  de  entorno  DJANGO_SETTINGS_MODULE.  El 
valor  de  DJANGO_SETTINGS_MODULE  debe  respetar  la  sintaxis  de  rutas  de  Python 
(por  ej.  misitio. settings.  Observa  que  el  modulo  de  configuracion  debe  de  encontrarse 
en  la  ruta  de  busqueda  para  las  importaciones  de  Python  (PYTHONPATH). 


DJANGOSETTINGSMODULE 

Con  todos  estos  cambios  en  el  codigo,  la  siguiente  parte  de  este  capitulo  se  centra  en 
las  instrucciones  espetificas  para  desplegar  Django  en  distintos  entornos,  tal  como 
Apache,  Gunicorn...  Las  instrucciones  son  diferentes  para  cada  entorno,  pero  una 
cosa  es  la  misma:  en  cada  caso  necesitas  decide  al  servidor  Web  cual  es  tu: 
DJANGO_SETTINGS_MODULE.  Este  es  el  punto  de  entrada  de  tu  aplicacion  Django. 

DJANGO_SETTINGS_MODULE  enlaza  tu  archivo  de  configuraciones,  el  cual 
apunta  a ROOTJJRLCONF,  que  a su  vez  enlaza  tus  vistas  y asi  sucesivamente. 

El  objeto  application 

El  concepto  clave  para  implementar  usando  WSGI  es  el  llamable  application  que  es  el 
modulo  que  el  servidor  de  aplicaciones  utiliza  para  comunicarse  con  el  codigo 
Python.  Este  comunmente  se  provee  como  un  objeto  llamado  application  el  cual  es 
un  modulo  Python  accesible  por  el  servidor. 

El  comando  startproject  crea  un  archivo  llamado  wsgi.py  este  contiene  un  modulo 
llamable  llamado  application.  Este  es  usado  tanto  en  el  servidor  de  desarrollo,  como 
en  el  despliegue  para  production,  por  lo  que  no  necesitas  crearlo. 

El  servidor  WSGI  obtiene  la  ruta  de  la  configuracion  del  llamable  application.  El 
servidor  de  desarrollo  “runserver”  lee  la  configuracion  de  WSGI_APPLICATION,  la 
cual  enlaza  a el  llamable  application  en  el  archivo  wsgi.py,  lo  mismo  pasa  con  un 
servidor  en  production. 

Configura  el  modulo  settings 

Cuando  el  servidor  WSGI  carga  tu  aplicacion,  Django  necesita  importar  el  modulo  de 
configuraciones  settings  - que  es  donde  se  define  completamente  la  aplicacion. 

Django  usa  la  variable  de  entorno  DJANGO_SETTINGS_MODULE  que  contiene  la 
ruta  para  localizar  apropiadamente  este  modulo.  Puedes  usar  diferentes  valores  para 
desarrollo  y production;  todo  depende  de  como  organices  tus  configuraciones. 

Si  esta  variable  no  esta  establecida,  el  valor  por  defecto  es  misitio. settings,  donde 
misitio  es  el  nombre  de  tu  proyecto  y settings  es  el  nombre  del  archivo  settings.py. 
Esta  es  la  forma  en  que  runserver  carga  el  archivo  de  configuraciones  por  defecto. 
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Como  desplegar  con  WSGI 

La  plataforma  dominante  de  implementation  para  Django  es  WSGI,  el  estandar 
Python  para  servidores  y aplicaciones  Web. 

El  comando  administrativo  startproject  establece  por  defecto,  un  simple  archivo 
de  configuracion  WSGI,  el  cual  puedes  personalizarse  segun  las  necesidades  de  tu 
proyecto,  y directamente  adaptarse  a cualquier  servidor  que  ofrezca  soporte  para 
WSGI,  como  los  siguientes  servidores: 

■ mod_wsgi 

■ apache 

■ gunicorn 

■ uwsgi 


Usando  Django  con  Apache  y mod_wsgi 


Desplegar  Django  con  Apache  y mod_wsgi  es  la  manera  probada  y comprobada  de 
usar  Django  en  un  servidor  en  production. 

mod_wsgi  es  un  modulo  de  Apache  que  puede  hospedar  cualquier  aplicacion 
Python  WSGI,  incluyendo  Django.  El  cual  trabaja  con  cualquier  version  de  Apache 
que  soporte  mod_wsgi. 

La  Documentation  oflcial  es  fantastica,  y el  codigo  fuente  incluye  detalles  sobre  el 
modo  de  usar  mod_wsgi.  Por  lo  que  probablemente  quieras  empezar  por  leer  la 
documentation  sobre  instalacion  y configuracion. 

Configuracion  basica 

Para  configurar  Django  con  mod_wsgi,  primero  debes  asegurarte  de  que  tienes 
instalado  Apache  con  el  modulo  mod_wsgi  activado.  Esto  usualmente  significa  tener 
una  directiva  Load  Module  en  tu  archivo  de  configuracion  de  Apache.  Parecida  a esta: 

LoadModule  wsgijnodule  /modules/mod_wsgi.so 

Una  vez  que  has  instalado  y activado  mod_wsgi,  edita  el  archivo  httpd.conf  de  tu 
servidor  Web  Apache  y agrega  lo  siguiente.  Si  estas  usando  una  version  de  Apache 
anterior  a la  2.4,  remplaza  Require  all  granted  con  Allow  from  all  y tambien  agrega  la 
linea  Order  deny, allow  arriba  de  esta. 

WSGIScriptAlias  / /path/to/mysite.com/mysite/wsgi.py 
WSGIPythonPath  /path/to/mysite.com 
<Directory  /path/to/mysite.com/mysite> 

<Files  wsgi.py> 

Require  all  granted 
</Files> 

</Directory> 

El  primer  fragmento  de  la  linea  WSGIScriptAlias  es  la  ruta  base  que  quieres  servir 
tu  aplicaciones  en  (/  indica  la  raiz  de  la  url)  y la  segunda  es  la  localization  de  el 
“archivo  WSGI”  -ver  mas  abajo  en  tu  sistema,  usualmente  dentro  del  paquete  de  tu 
proyecto  (misitio  en  este  ejemplo.)  Esto  le  dice  al  servidor  Apache  “Usa  mod_wsgi 
para  cualquier  petition  URL  en  7’  o bajo  ella,  usando  la  aplicacion  WSGI  definida  en 
ese  archivo”. 
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La  linea  WSGIPythonPath  se  asegura  que  el  paquete  del  proyecto  este  disponible 
para  importar  la  ruta  de  busqueda  de  Python;  en  otras  palabras  se  asegura  que 
import  misitio  trabaje. 

La  pieza  <Directory>  solo  se  asegura  de  que  Apache  pueda  acceder  al  archivo 
wsgi.py,  ya  que  se  utiliza  para  apuntar  a lugares  de  nuestra  sistema  de  archivos, 

Lo  siguiente  que  necesitas  hacer,  es  asegurarte  que  exista  una  archivo  wsgi.py,  como 
seguramente  te  diste  cuenta  el  comando  startproject  crea  este  archivo  por  defecto  al 
crear  el  proyecto,  de  otra  forma  tendrias  que  crear  este  archivo  manualmente. 


% Advertencia:  Si  varios  sitios  estan  siendo  ejecutados  en  un  simple  proceso 
mod_wsgi,  todos  ellos  usaran  las  configuraciones  de  cualquiera  de  los  procesos  que 
corra  primero.  Esto  puede  se  solventado  con  un  pequeno  cambio  en  el  archivo 
wsgi.py  (ve  los  comentarios  en  el  archivo  para  detalles)  o puedes  asegurarte  de  cada 
sitio  sea  ejecutado  en  un  proceso  independiente,  usando  su  propio  demonio, 
sobrescribiendo  el  valor  por  defecto  usando: 

os.environ["DJANGO_SETTINGS_MODULE"]  = "misitio. settings"  enel  arhvio  wsgi.py 


Usando  virtualenv 


Si  has  instalado  las  dependencias  Python  de  tu  proyecto  dentro  de  virtualenv, 
necesitas  agregar  la  ruta  de  “virtualenv’s”  al  directorio  site-packages,  asi  como  el 
camino  de  busqueda.  Para  hacer  esto  agrega  una  ruta  de  busqueda  adicional  a la 
directiva  WSGIPythonPath,  con  las  multiples  rutas  separadas  por  dos  puntos  (:)  si 
estas  usando  un  sistema  del  tipo  UNIX,  o punto  y coma  (;)  si  estas  usando  Windows. 
Si  cualquier  parte  de  la  ruta  al  directorio  contiene  caracteres  como  espacios,  la 
cadena  completa  de  argumentos  para  WSGIPythonPath  debe  ser  citada: 

WSGIPythonPath  /path/to/mysite.com:/path/to/your/venv/lib/python3.X/site-packages 

Asegurate  de  darle  la  ruta  correcta  a tu  virtualenv,  y remplazar  python3.X  con  la 
version  correcta  de  Python  (por  ejemplo  python3.4). 

Usando  mod_wsgi  en  modo  demonio 


“Modo  Demonio”  es  el  modo  recomendado  para  ejecutar  mod_wsgi  (en  plataformas 
que  no  son  Windows).  Para  crear  el  grupo  de  procesos  requeridos  por  el  demonio  y 
delegar  la  instancia  Django  para  ejecutarse,  necesitas  agregar  apropiadamente  las 
directivas  WSGIDaemonProcess  y WSGIProcessGroup.  Un  cambio  mas  es  requerido 
en  la  anterior  configuration  si  utilizas  el  modo  demonio  no  puedes  usar 
WSGIPythonPath,  en  lugar  de  eso  debes  usar  la  option  python-path  para 
WSGIDaemonProcess,  por  ejemplo: 

WSGIDaemonProcess  example.com  python- 
path=/path/to/mysite.com:/path/to/venv/lib/python3. 4/site-packages 

Otra  option  para  servir  los  archivos  multimedia,  que  no  sea  el  mismo  VirtualHost 
Apache  que  usa  Django,  puedes  configurar  Apache  para  que  sirva  algunas  URLs 
estaticas  y otras  usando  la  interface  mod_wsgi  para  Django 

Este  ejemplo  configura  Django  en  la  raiz  del  sitio,  pero  explicitamente  sirve 
robots.txt,  favicon.ico,  y cualquier  archivo  CSS,  y cualquier  cosa  en  el  espacio  de  URL 
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/static/  y /media/  sera  tratado  como  archivos  estaticos.  Todas  las  demas  URLs  sera 
servidas  usando  mod_wsgi: 

Alias  /robots.txt  /path/to/mysite.com/static/robots.txt 


Alias  /robots.txt  /path/to/mysite. com/static/robots. txt 
Alias  /favicon. ico  /path/to/mysite. com/static/favicon. ico 
AliasMatch  A/([A/]*\.  css)  /path/to/mysite.  com/static/styles/$l 
Alias  /media/  /path/to/mysite. com/media/ 

Alias  /static/  /path/to/mysite. com/static/ 

<Directory  /path/to/mysite. com/static> 

Require  all  granted 
</Directory> 

<Directory  /path/to/mysite. com/media> 

Require  all  granted 
</Directory> 

WSGIScriptAlias  / /path/to/mysite. com/mysite/wsgi.py 
<Directory  /path/to/mysite. com/mysite> 

<Files  wsgi.py> 

Require  all  granted 
</Files> 

</Directory> 

Si  estas  usando  una  version  de  Apache  anterior  a la  2.4,  remplaza  Require  all 
granted  con  Allow  from  all  y tambien  agrega  la  linea  Order  deny,  allow  arriba  de  esta. 


Como  servir  los  archivos  de  la  interfaz  administrativa 


Cuando  django.contrib.staticfiles  esta  en  el  archivo  de  configuraciones  en  la  variable 
INSTALLED_APPS  El  entorno  de  desarrollo  de  Django  sirve  automaticamente  los 
archivos  estaticos  de  la  interfaz  administrativa  (y  de  cualquier  aplicacion  instalada). 
Este  no  es  el  caso  cuando  usas  otro  servidor  para  este  trabajo.  Tu  eres  responsable  de 
configurar  Apache  o cualquier  otro  servidor  Web  que  utilices,  para  servir  los  archivos 
de  la  interfaz  administrativa. 

Los  archivos  de  la  interfaz  administrativa  se  localizan  en 
django/contrib/admin/static/admin  en  la  distribucion  de  Django  Es  fuertemente 
recomendable  usar  django.contrib.staticfiles  para  manejar  los  archivos  de  la  interfaz 
administrativa  (Junto  con  el  servidor  Web,  esto  significa  que  puedes  usar  el  comando 
collectstatic  para  recolectar  todos  los  archivos  estaticos  en  STATIC_ROOT  y luego 
configurar  el  servidor  Web  para  servir  STATIC_ROOT,  pero  aqui  estan  otras  tres 
formas  de  hacer  lo  mismo: 

Crea  un  enlace  simbolico  a los  archivos  estaticos  de  la  interfaz  administrativa 
desde  la  raiz  de  Apache  (esto  puede  requerir  usar  +FollowSymLinks  en  la 
configuration  de  Apache) 

Usa  una  directiva  Alias,  como  mostramos  arriba,  un  alias  apropiado  a la  URL 
(probablemente  STATIC_URL  + admin/)  a la  position  actual  de  los  archivos  estaticos. 

Copia  los  archivos  estaticos  de  la  interfaz  administrativa  de  modo  que  se  localicen 
dentro  de  la  raiz  de  Apache. 
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Como  usar  Django  con  Gunicorn 

Gunicorn  (‘Unicornio  verde’)  es  un  servidor  WSGI  implementado  en  Python.  No 
tiene  dependencias  y es  facil  de  instalar  y usar. 

Hay  dos  formas  de  usar  Gunicorn  con  Django.  La  primera  es  tratar  a Gunicorn 
simplemente  como  otra  aplicacion  WSGI.  La  segunda  es  usar  Gunicorn  de  forma 
especial  integrandolo  con  Django. 

Una  vez  instalado  Gunicorn,  tenemos  disponible  un  comando  gunicorn  que  inicia 
el  proceso  del  servidor  Gunicorn.  Esto  es  tan  simple,  ya  que  gunicorn  solo  necesita 
ser  llamado  con  la  localization  del  objeto  aplication  del  WSGI.: 

gunicorn  [OPTIONS]  MODULO 

Donde  MODULO  es  un  patron  del  tipo  NOMBRE_MODULO:NOMBRE_VARIABLE. 
El  nombre  del  modulo  debe  ser  la  ruta  completa  al  proyecto,  mientras  que  el  nombre 
de  la  variable  se  refiere  al  llamable  WSGI  el  cual  debe  de  encontrarse  en  el  modo 
especificado. 

Asi  para  un  tipico  proyecto  Django,  invocar  a gunicorn  se  veria  asl: 
gunicorn  misitio.wsgi:application 

Donde  misitio  es  el  nombre  del  proyecto  y application  es  el  llamable  del  WSGI. 
(Esto  requiere  que  el  proyecto  este  en  la  ruta  de  busqueda  de  Python;  la  forma  mas 
simple  de  hacer  esto,  es  asegurarse  de  ejecutar  el  comando  “gunicorn”  desde  el 
mismo  directorio  en  que  esta  el  archivo  manage.py) 


Como  usar  Django  con  uWSGI 


uWSGI  es  un  servidor  rapido  codificado  en  C,  autoregenerable  y desarrollado  como 
una  aplicacion  amigable  para  los  administradores  de  sistemas. 

Prerrequisitos:  Uwsgi 

La  wiki  de  WSGI  describe  algunos  metodo  de  instalacion.  Usando  pip,  el  manejador 
de  paquetes  python  puedes  instalar  cualquier  version  de  uWSGI  con  un  simple 
comando.  Por  ejemplo: 

# Instala  la  version  estable. 

sudo  pip  install  uwsgi 

# O installa  la  LTS  (Soporte  a largo  plazo). 

sudo  pip  install  http://projects.unbit.it/downloads/uwsgi-lts.tar.gz 


% Advertencia:  Algunas  distribuciones,  incluidas  Debian  y Ubuntu,  incluyen 
versiones  antiguas  de  uWSGI  que  no  cumplen  las  especificaciones  WSGI.  Versiones 
anteriores  a la  1.2.6  no  llaman  a close  en  el  objeto  de  repuesta  despues  de  manejar 
una  petition.  En  estos  casos  django.core.signals.request_finished  no  envia  las 
senales.  Esto  puede  dar  lugar  a conexiones  lentas  a los  servidores  de  la  base  de  datos 
y memcache. 
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WSGI  model 


uWSGI  opera  en  un  modelo  cliente-servidor.  El  servidor  web  (por  ejemplo  nginx, 
Apache)  se  comunicacn  con  un  proceso  del  “trabajo”  django-uwsgi  para  servir 
dinamicamente  el  contexto.  Consulta  la  documentation  a fondo  de  uWSGI’s  para 
obtener  mas  detalles. 

Configurar  e iniciar  el  servidor  uWSGI 

uWSGI  soporta  multiples  formas  para  configurar  el  proceso.  Puede  iniciar  mediante 
un  comando  o leyendo  un  archivo  de  configuraciones  de  inicio.  Puedes  consultar 
mas  ejemplos  y la  documentation  de  uWSGI  para  obtener  detalles  mas  especificos. 
Este  es  un  ejemplo  de  un  comando  para  iniciar  el  servidor  uWSGI: 

uwsgi  --chdir=/path/to/your/project  \ 

-module=misitio.wsgi:application  \ 

--env  DJANGO_SETTINGS_MODULE=misitio. settings  \ 

-master  ~pidfile=/tmp/project-master.pid  \ 

-socket=127. 0.0. 1:49152  \#  puede  usar  tambien  un  archivo. 

~processes=5  \ # numero  de  procesos 

~uid=1000  -gid=2000  \ # si  es  root,  uwsgi  puede  revocar  provilegios 
~harakiri=20  \ # para  procesos  que  toman  mas  de  20  segundos 
-max-requests=5000  \#  numero  maximo  de  peticiones 
-vacuum  \#  limpia  el  entorno  y sale. 

~home=/path/to/virtual/env  \ # ruta  opcional  para  virtualenv 
-daemonize=/var/log/uwsgi/yourproject.log  # procesos  en  Segundo  piano 

Este  asume  que  estas  situado  en  el  nivel  superior  de  un  paquete  llamado  misitio  y 
dentro  del  existe  un  modulo  wsgi.py,  que  contienen  un  objeto  application  WSGI.  No 
deberias  tener  ningun  problema  si  ejecutaste  el  comando  django-admin.py 
startproject  misitio,  ya  que  este  se  encarga  de  crear  la  estructura  del  proyecto  por 
default.  Si  este  archivo  no  existe  necesitas  crearlo. 

Las  opciones  especificas  de  Django  son: 

■ chdir:  La  ruta  al  directorio,  que  necesita  estar  en  la  ruta  de  importation  de 
Python.  - es  decir  el  directorio  que  contiene  el  paquete  misitio 

■ module:  El  modulo  WSGI  para  usar  -probablemente  el  modulo  misitio.wsgi 
que  startproject  creo. 

■ env:  Debe  contener  por  lo  menos  DJANGO_SETTINGS_MODULE. 

■ home:  Opcionalmente  la  ruta  al  proyecto,  si  estas  usando  virtualenv. 

Ejemplo  de  un  archivo  de  configuration  ini: 

[uwsgi] 

chdir=/path/to/your/project 

module=misitio.wsgi:application 

master=True 

pidfile=/tm  p/project-master,  pid 

vacuum=True 

max-requests=5000 
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daemonize=/var/log/uwsgi/yourproject.log 

Consulta  el  manejo  de  procesos  uWSGI  para  mas  information  sobre  iniciar, 
detener  y recargar  los  procesos  del  servidor  uWSGI. 


Lighttpd 


lighttpd  es  un  servidor  Web  liviano  usado  habitualmente  para  servir  archivos 
estaticos.  Admite  FastCGI  en  forma  nativa  y por  lo  tanto  es  tambien  una  option  ideal 
para  servir  tanto  paginas  estaticas  como  dinamicas,  si  tu  sitio  no  tiene  necesidades 
especificas  de  Apache. 

Asegurate  que  mod_fastcgi  esta  en  tu  lista  de  modulos,  en  algun  lugar  despues  de 
mod_rewrite  y mod_access,  pero  no  antes  de  mod_accesslog.  Probablemente  desees 
tambien  mod_alias,  para  servir  los  archivos  media  de  la  interfaz  administrativa. 
Agrega  lo  siguiente  a tu  archivo  de  configuracion  de  lighttpd: 

server. document-root  = "/home/user/public_html" 
fastcgi. server  = ( 

"/mysite.fcgi"  =>  ( 

"main"  =>  ( 

# Use  host  / port  instead  of  socket  for  TCP  fastcgi 

# "host"  =>  "127.0.0.1", 

# "port"  =>  3033, 

"socket"  =>  "/home/user/mysite.sock", 

"check-local"  =>  "disable", 

) 

)■ 

) 

alias. url  = ( 

"/media"  =>  "/home/user/django/contrib/admin/media/", 

) 

url.rewrite-once  = ( 

"A(/media.*)$"  =>  "$1", 

"A/favicon\.ico$"  =>  "/media/favicon. ico", 

"A(/.*)$"  =>  "/mysite.fcgi$l", 

) 


Ejecutando  Multiples  Sitios  Django  en  Una  Instancia  lighttpd 


lighttpd  te  permite  usar  “configuracion  conditional”  para  permitir  la  configuracion 
personalizada  para  cada  host.  Para  especificar  multiples  sitios  FastCGI,  solo  agrega 
un  bloque  conditional  en  torno  a tu  configuracion  FastCGI  para  cada  sitio: 


# If  the  hostname  is  ’www.examplel.com’... 

$HTTP["host"]  ==  "www.examplel.com"  { 
server. document-root  = "/foo/sitel" 
fastcgi. server  = ( 
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) 

} 

# If  the  hostname  is  ’www.example2.com’... 

$HTTP["host"]  ==  "www.example2.com"  { 
server. document-root  = ”/foo/site2" 
fastcgi. server  = ( 

) 

} 


Puedes  tambien  ejecutar  multiples  instalaciones  de  Django  en  el  mismo  sitio 
simplemente  especificando  multiples  entradas  en  la  directiva  fastcgi.  server.  Agrega 
un  host  FastCGI  para  cada  una. 


Escalamiento 


Ahora  que  sabes  como  conflgurar  Django  en  un  sitio  en  production,  veamos  como 
puedes  escalar  una  instalacion  Django.  Esta  section  explica  como  puede  escalar  un 
sitio  desde  un  servidor  unico  a un  cluster  de  gran  escala  que  pueda  servir  millones  de 
peticiones  por  hora. 

Es  importante  notar,  sin  embargo,  que  cada  sitio  grande  es  grande  de  diferentes 
formas,  por  lo  que  escalar  es  cualquier  cosa  menos  una  operation  de  una  solution 
unica  para  todos  los  casos.  La  siguiente  cobertura  debe  ser  suficiente  para  mostrar  el 
principio  general,  y cuando  sea  posible,  trataremos  de  senalar  donde  se  puedan  elegir 
distintas  opciones. 

Primero,  haremos  una  buena  presuposicion,  y hablaremos  exclusivamente  acerca 
de  escalamiento  bajo  Apache  y wsgi.  A pesar  de  que  conocemos  vario  casos  exitosos 
de  desarrollos  FastCGI  y mod_python  medios  y grandes, 
familiarizados  con  Apache. 

Ejecutando  en  un  Servidor  Unico 

La  mayoria  de  los  sitios  Web,  empiezan  ejecutandose  en  un 
servidor  unico,  con  una  arquitectura  parecida  a la  de  la 
Figura  12-1. 

Esto  funciona  bien  para  sitios  pequenos  y medianos,  y es 
relativamente  barato  - puedes  instalar  un  servidor  unico 
disenado  para  Django  por  menos  de  3,000  dolares. 

Imagen  12-1:  Ejecutando  unicamente  un  servidor. 

Sin  embargo,  a medida  que  el  trafico  se  incremente,  caeras  rapidamente  en 
contention  de  recurs  os  enlre  las  diferentes  piezas  de  software.  Los  servidores  de  base 
de  datos  y los  servidores  Web  adoran  tener  el  servidor  entero  para  ellos,  y cuando 
corren  en  el  mismo  servidor  siempre  terminan  “peleando”  por  los  mismos  recursos 
(RAM,  CPU)  que  prefieren  monopolizar. 


estamos  mucho  mas 

* 


S0TVGT 
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Esto  se  resuelve  facilmente  moviendo  el  servidor  de  base 
de  datos  a una  segunda  maquina,  como  se  explica  en  la 
siguiente  section. 

Separando  el  Servidor  de  Bases  de  Datos 

En  lo  que  tiene  que  ver  con  Django,  el  proceso  de  separar  el 
servidor  de  bases  de  datos  es  extremadamente  sencillo: 
simplemente  necesitas  cambiar  la  configuration  de 
DATABASE_E10ST  a la  IP  o nombre  DNS  de  tu  servidor. 
Probablemente  sea  una  buena  idea  usar  la  IP  si  es  posible,  ya 
que  depender  de  la  DNS  para  la  conexion  entre  el  servidor 
Web  y el  servidor  de  bases  de  datos  no  se  recomienda. 

Con  un  servidor  de  base  de  datos  separado,  nuestra 
arquitectura  ahora  se  ve  como  en  la  Imagen  12-2. 

Imagen  12-2:  Moviendo  la  base  de  datos  a un  servidor 

dedicado. 


database  server 


Aqui  es  donde  empezamos  a movernos  hacia  lo  que  usualmente  se  llama  una 
arquitectura  n-tier.  No  te  asustes  por  la  terminologia  - solo  se  reflere  al  hecho  de  que 
diferentes  “tiers”  de  la  pila  Web  separadas  en  diferentes  maquinas  fisicas. 

A esta  altura,  si  anticipas  que  en  algun  momento  vas  a necesitar  crecer  mas  alia  de 
un  servidor  de  base  de  datos  unico,  probablemente  sea  una  buena  idea  empezar  a 
pensar  en  pooling  de  conexiones  y/o  replication  de  bases  de  datos. 
Desafortunadamente,  no  hay  suficiente  espacio  para  hacerle  justicia  a estos  temas  en 
este  libro,  asi  que  vas  a necesitar  consultar  la  documentation  y/o  a la  comunidad  de 
tu  base  de  datos  para  mas  information. 


Ejecutando  un  Servidor  de  Medios  Separado 


Aun  tenemos  un  gran  problema  por  delante, 
usando  unicamente  un  servidor:  servir  los 
archivos  media  desde  la  misma  caja  que 
maneja  el  contenido  dinamico. 

Estas  dos  actividades  tienen  su  mejor 
performance  bajo  distintas  circunstancias,  y 
encerrandolas  en  la  misma  caja  terminaras  con 
que  ninguna  de  las  dos  tendra  un  buen 
rendimiento.  Asi  que  el  siguiente  paso  es 
separar  los  medios  - esto  es,  todo  lo  que  no  es 
generado  por  una  vista  de  Django  - a un 
servidor  dedicado  (ver  Imagen  12-3). 

Imagen  12-3:  Separando  el  servidor  de 
medios. 


database  server 


Idealmente,  este  servidor  de  medios  deberia  ejecutarse  en  un  servidor  Web, 
optimizado  para  la  entrega  de  medios  estaticos.  lighttpd  y tux 
(http://www.djangoproject.eom/r/tux/)  son  dos  excelentes  elecciones  aqui,  pero  un 
servidor  Apache  bien  ‘personalizado’  tambien  puede  funcionar. 

Para  sitios  pesados  en  contenidos  estaticos  (fotos,  videos,  etc.),  moverse  a un 
servidor  de  medios  separado  es  doblemente  importante  y deberia  ser  el  primer  paso 
en  el  escalamiento  hacia  arriba. 
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De  todos  modos,  este  paso  puede  ser  un  poco  delicado.  Si  tu  aplicacion  necesita 
subir  archivos  Django  necesita  poder  escribir  sobre  los  medios  ‘subidos’  en  el 
servidor  de  medios.  (la  configuracion  de  MEDIA_ROOT  controla  donde  escriben 
estos  medios).  Si  un  medio  habita  en  otro  servidor,  de  todas  formas  necesitas 
organizar  una  forma  de  que  esa  escritura  se  pueda  hacer  a traves  de  la  red. 


Implementando  Balance  de  Carga  y Redundancia 

A esta  altura,  ya  hemos 
separado  las  cosas  todo  lo 
posible. 

Esta  configuracion  de 
tres  servidores  deberia 
manejar  una  cantidad 
muy  grande  de  trafico  - 
nosotros  servimos 

alrededor  de  10  millones 
de  hits  por  dia  con  una 
arquitectura  de  este  tipo- 
asi  que  si  creces  mas  alia, 
necesitaras  empezar  a 
agregar  redundancia. 

En  realidad,  esto  es 
algo  bueno.  Una  mirada  a 
la  Figura  12-3  te  permitira 
ver  que  si  falla  aunque  sea 
uno  solo  de  los  servidores, 
el  sitio  entero  se  cae.  Asi 
que  a medida  que  agregas 
servidores  redundantes, 
no  solo  incrementas 
capacidad,  sino  tambien 
confiabilidad. 

Imagen  12-4:  Configuracion  de  un  server  redundante  con  balance  de  carga. 

Para  este  ejemplo,  asumamos  que  el  primero  que  se  ve  superado  en  capacidad  es 
el  servidor  Web.  Es  facil  tener  multiples  copias  de  un  sitio  Django  ejecutando  en 
diferente  hardware.  - simplemente  copia  el  codigo  en  varias  maquinas,  e inicia 
Apache  en  cada  una  de  ellas. 

Sin  embargo,  necesitas  otra  pieza  de  software  para  distribuir  el  trafico  entre  los 
servidores:  un  balanceador  de  carga.  Puedes  comprar  balanceadores  de  carga  por 
hardware  caro  y propietario,  pero  existen  algunos  balanceadores  de  carga  por 
software  de  alta  calidad  que  son  open  source. 

mod_proxy  de  Apache  es  una  option,  pero  hemos  encontrado  que  Perlbal 
(http://www.djangoproject.eom/r/perlbal/)  es  simplemente  fantastico.  Es  un 
balanceador  de  carga  y proxy  inverso  escrito  por  las  mismas  personas  que  escribieron 
memcached. 

Con  los  servidores  Web  en  cluster,  nuestra  arquitectura  en  evolution  empieza  a 
verse  mas  compleja,  como  se  ve  en  la  Imagen  12-4. 

Observa  que  en  el  diagrama  nos  referimos  a los  servidores  Web  como  “el  cluster” 
para  indicar  que  el  numero  de  servidores  basicamente  es  variable.  Una  vez  que  tienes 
un  balanceador  de  carga  en  el  frente,  puedes  agregar  y eliminar  servidores  Web  back- 
end sin  perder  un  segundo  fuera  de  servicio. 
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Vamos  a lo  grande 


En  este  punto,  los  siguientes  pasos  son  derivaciones  del  ultimo: 

A medida  que  necesites  mas  performance  en  la  base  de  datos,  necesitaras  agregar 
servidores  de  base  de  datos  replicados.  MySQL  tiene  replicacion  incorporada;  los 
usuarios  de  PostgreSQL  deberian  mirar  a Slony 

(http://www.djangoproject.eom/r/slony/)  y pgpool 

(http://www.djangoproject.eom/r/pgpool/)  para  replicacion  y pooling  de 

conexiones,  respectivamente. 

Si  un  solo  balanceador  de  carga  no  es  suficiente,  puedes  agregar  mas  maquinas 
balanceadoras  de  carga  y distribuir  entre  ellas  usando  DNS  round-robin. 

Si  un  servidor  unico  de  medios  no  es  suficiente,  puedes  agregar  mas  servidores  de 
medios  y distribuir  la  carga  con  tu  cluster  de  balanceadores  de  carga. 

Si  necesitas  mas  almacenamiento  cache,  puedes  agregar  servidores  de  cache 
dedicados. 

En  cualquier  etapa,  si  un  cluster  no  tiene  buena  performance,  puedes  agregar  mas 
servidores  al  cluster. 

Despues  de  algunas  de  estas  iteraciones,  una  arquitectura  de  gran  escala  debe 
verse  como  en  la  Imagen  12-5 


web  server  cluster 


cache  cluster 


database  server  cluster 


Imagen  12-5.  Un  ejemplo  de  configuration  de  Django  de  gran  escala. 

A pesar  de  que  mostramos  solo  dos  o tres  servidores  en  cada  nivel,  no  hay  un 
limite  fundamental  a cuantos  puedes  agregar. 
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Ajuste  de  Performance 


Si  tienes  grandes  cantidades  de  dinero,  simplemente  puedes  irle  arrojando  hardware 
a los  problemas  de  escalado.  Para  el  resto  de  nosotros,  sin  embargo,  el  ajuste  de 
performance  es  una  obligation. 


Nota:  Incidentalmente,  si  alguien  con  monstruosas  cantidades  de  dinero  esta 
leyendo  este  libro,  por  favor  considere  hacer  una  donation  sustancial  al  proyecto 
Django.  Aceptamos  diamantes  en  bruto  y lingotes  de  oro. 


Desafortunadamente,  el  ajuste  de  performance  es  mas  un  arte  que  una  ciencia,  y 
es  aun  mas  dificil  de  escribir  sobre  eso  que  sobre  escalamiento.  Si  estas  pensando 
seriamente  en  desplegar  una  aplicacion  Django  de  gran  escala,  deberas  pasar  un 
buen  tiempo  aprendiendo  como  ajustar  cada  pieza  de  tu  stack. 

Las  siguientes  secciones,  sin  embargo,  presentan  algunos  tips  especificos  del 
ajuste  de  performance  de  Django  que  hemos  descubierto  a traves  de  los  anos. 

No  hay  tal  cosa  como  demasiada  RAM 


Incluso  la  RAM  mas  costosa  es  relativamente  costeable  en  estos  dias.  Compra  toda  la 
RAM  que  puedas,  y despues  compra  un  poco  mas. 

Los  procesadores  mas  rapidos  no  mejoran  la  performance  tanto.  La  mayoria  de  los 
servidores  Web  desperdician  el  90%  de  su  tiempo  esperando  I/O  del  disco.  En 
cuantos  empieces  a swappear,  la  performance  directamente  se  muere.  Los  discos 
mas  rapidos  pueden  ayudar  levemente,  pero  son  mucho  mas  caros  que  la  RAM,  asi 
que  no  cuentan. 

Si  tienes  varios  servidores,  el  primer  lugar  donde  poner  tu  RAM  es  en  el  servidor  de 
base  de  datos.  Si  puedes,  compra  suficiente  ram  como  para  tener  toda  tu  base  de 
datos  en  memoria.  Esto  no  es  tan  dificil.  Hemos  disenado  sitios  que  incluye  medio 
millon  de  articulos  en  menos  de  menos  de  2 GB  de  espacio. 

Despues,  maximiza  la  RAM  de  tu  servidor  Web.  La  situation  ideal  es  aquella  en  la 
que  ningun  servidor  swapea  - nunca.  Si  llegas  a ese  punto,  debes  poder  manejar  la 
mayor  parte  del  trafico  normal. 

Deshabilita  Keep-Alive 

Keep-Alive  es  una  caracteristica  de  HTTP  que  permite  que  multiples  pedidos  HTTP 
sean  servidos  sobre  una  conexion  TCP  unica,  evitando  la  sobrecarga  de  conectar  y 
desconectar. 

Esto  parece  bueno  a primera  vista,  pero  puede  asesinar  al  performance  de  un  sitio 
Django.  Si  estas  sirviendo  medios  desde  un  servidor  separado,  cada  usuario  que  este 
navegando  tu  sitio  solo  requerira  una  pagina  del  servidor  Django  cada  diez  segundos 
aproximadamente.  Esto  deja  a los  servidores  HTTP  esperando  el  siguiente  pedido 
keep-alive,  y un  servidor  HTTP  ocioso  consume  RAM  que  deberia  estar  usando  un 
servidor  activo. 

Usa  memcached 

A pesar  de  que  Django  admite  varios  back-ends  de  cache  diferentes,  ninguno  de  ellos 
siquiera  se  acerca  a ser  tan  rapido  como  memcached.  Si  tienes  un  sitio  con  trafico 
alto,  ni  pierdas  tiempo  con  los  otros  — usa  directamente  memcached. 


263  CAPITULO  12  DESPLEGANDO  DJANGO 


Usa  memcached  siempre 

Por  supuesto,  seleccionar  memcached  no  te  hace  mejor  si  no  lo  usas  realmente.  El 
capitulo  te  dice  como  usarlo:  aprende  a usar  el  framework  de  cache  de  Django,  y 
usalo  en  todas  las  partes  que  te  sea  posible.  Un  uso  de  cache  agresivo  y preemptico  es 
usualmente  lo  unico  que  se  puede  hacer  para  mantener  un  sitio  Web  funcionando 
bajo  el  mayor  trafico. 

Unete  a la  Conversation 

Cada  pieza  del  stack  de  Django  - desde  Linux  a Apache  a PostgreSQL  o MySQL  - 
tiene  una  comunidad  maravillosa  detras.  Si  realmente  quieres  obtener  ese  ultimo  1% 
de  tus  servidores,  unete  a las  comunidades  open  source  que  estan  detras  de  tu 
software  y pide  ayuda.  La  mayoria  de  los  miembros  de  la  comunidad  del  software 
libre  estaran  felices  de  ayudar. 

Y tambien  asegurate  de  unirte  a la  comunidad  Django.  Tus  humildes  autores  son 
solo  dos  miembros  de  un  grupo  increiblemente  activo  y creciente  de  desarrolladores 
Django.  Nuestra  comunidad  tiene  una  enorme  cantidad  de  experiencia  colectiva  para 
ofrecer. 

<?,Que  sigue? 

El  resto  de  los  capitulos  se  enfocan  en  otras  caracteristicas  de  Django,  que  puedes  o 
no  necesitar,  dependiendo  de  tus  aplicaciones.  Sientete  libre  de  leerlos  en  el  orden 
que  prefieras. 


Baterias  incluidas 


CAPITULO  13 


Generacion  de  contenido  no 

HTML 


U sualmente  cuando  hablamos  sobre  desarrollo  de  sitios  Web,  hablamos  de 
producir  HTML.  Por  supuesto,  hay  mucho  mas  que  contenido  HTML  en  la  Web;  la 
usamos  para  distribuir  datos  en  todo  tipo  de  formatos:  rss,  cvs,  pdfs,  imagenes, 
videos  y asi  sucesivamente. 

Hasta  ahora  nos  hemos  concentrado  en  el  caso  comun  de  la  production  de  HTML, 
pero  en  ese  capitulo  tomaremos  un  ligero  desvio  y veremos  como  usar  Django  para 
producir  otro  tipo  de  contenido. 

Django  posee  varias  herramientas  utiles  que  puedes  usar  para  producir  algunos 
tipos  comunes  de  contenido  no  HTML: 

• Feeds  de  sindicacion  RSS /Atom 

• Mapas  de  sitios  haciendo  uso  de  Sitemaps  (un  formato  XML  originalmente 
desarrollado  por  Google  que  provee  de  ayuda  a motores  de  busqueda) 

Examinaremos  cada  una  de  esas  herramientas  un  poco  mas  adelante,  pero  antes 
cubriremos  los  principios  basicos. 


Lo  basico:  Vistas  y tipos  MIME 

^Recuerdas  esto  del  capitulo  3! 

"Una  funcion  vista,  o una  vista  por  abreviar,  es  simplemente  una  funcion  en  Python  que 
recibe  una  peticion  Web  y retoma  una  respuesta  Web.  Esta  respuesta  puede  ser  el 
contenido  HTML  de  una  pagina  Web,  una  redireccion,  un  error  404,  un  documento 
XML,  una  imagen...  en  realidad,  cualquier  cosa". 


Mas  formalmente,  una  funcion  vista  debe 

■ Aceptar  una  instancia  HttpRequest  como  primer  argumento. 

■ Retornar  una  instancia  HttpRequestsponse  como  respuesta. 

La  clave  para  retornar  contenido  no  HTML  desde  una  vista  reside  en  la  clase 
HttpResponse,  especificamente  en  el  argumento  mimetype  del  constructor. 
Cambiando  el  tipo  MIME,  podemos  indicarle  al  navegador  que  hemos  retornado  una 
respuesta  en  un  formato  diferente. 
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Por  ejemplo,  veamos  una  vista  que  devuelve  una  imagen  PNG.  Para  mantener  las 
cosas  sencillas,  simplemente  leeremos  un  fichero  desde  el  disco: 
from  django.http  import  HttpResponse 

def  mi_imagen(request): 

datosjmagen  = ("/ruta/a/imagen.png",  "rb  j.read() 

return  HttpResponse(datos_imagen,  mimetype-'imagen/png'j 

jEso  es  todo!  Si  sustituimos  la  ruta  de  la  imagen  en  la  llamada  a open()  con  la  ruta  a 
una  imagen  real,  podemos  usar  esta  vista  bastante  sencilla  para  servir  una  imagen,  y 
el  navegador  la  mostrara  correctamente. 

La  otra  cosa  importante  a tener  presente  es  que  los  objetos  HttpResponse 
implementan  el  API  estandar  de  Python  para  ficheros.  Esto  significa  que  podemos 
usar  una  instancia  de  HttpResponse  en  cualquier  lugar  donde  Python  (o  biblioteca  de 
terceros)  esperaun  fichero. 

Como  un  ejemplo  de  como  funciona  esto,  veamos  la  produccion  de  CSV  con 
Django. 


Produccion  de  CSV 


CSV  es  un  formato  de  datos  sencillo  que  suele  ser  usada  por  programas  de  hojas  de 
calculo.  Basicamente  es  una  serie  de  filas  en  una  tabla,  cada  celda  en  la  fila  esta 
separada  por  comas  (CSV  significa  comma-separated  values).  Por  ejemplo,  aqui 
tienes  una  lista  de  pasajeros  “problematicos”  en  lineas  aereas  en  formato  CSV: 


Ano,  Pasajeros  problematicos 

1995,146 

1996,184 

1997,235 

1998,200 

1999,226 

2000,251 

2001,299 

2002,273 

2003,281 

2004,304 

2005,203 


El  listado  anterior,  contiene  numeros  reales;  cortesia  de  la  Administration  Federal 
de  Aviation  (FAA)  de  E.E.U.U.  Tornados  de: 

® http: / / www.faa.gov/ data_statistics / passengers_cargo  / unruly_passengers / . 

Aunque  CSV  parezca  simple,  no  es  un  formato  que  ha  sido  definido  formalmente. 
Diferentes  programas  producen  y consumen  diferentes  variantes  de  CSV,  haciendo 
un  poco  complicado  usarlo.  Afortunadamente,  Python  incluye  una  biblioteca 
estandar  para  CSV,  llamada  csv;  que  es  bastante  robusta. 

Debido  a que  el  modulo  csv  opera  sobre  objetos  de  forma  similar  ha  como  lo  hace 
con  archivos,  es  muy  facil  usar  un  HttpResponse  en  lugar  de  un  fichero: 
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import  csv 

from  django.http  import  HttpResponse 

# Numero  de  pasajeros  problematicos  en  el  periodo  1995-2005.  En  una 

# aplicacion  real  estos  datos  probablemente  vendnan  de  una  base  de  datos 

# o de  algun  otro  tipo  de  almacenamiento  externo. 
PASAJEROS_PROBLEMATICOS  = [146,184,235,200,226,251,299,273,281,304,203] 

def  pasajeros_problematicos_csv(request): 

# Crea  un  objeto  HttpResponse  con  las  cabeceras  del  CVS  correctas. 

response  = HttpResponse(content_type- text/csv') 

response['Content-Disposition']  = 'attachment;  filename=problematicos.csv' 

# Crea  el  escritor  CSV  usando  un  HttpResponse  como  "archivo." 

writer  = csv.writer(response) 

writer.writerow(['Ano',  ’Pasajeros  problematicos  en  aerolfnea’]) 
for  (year,  num)  in  zip(range(1995,  2006),  PASAJEROS_PROBLEMATICOS): 
writer. writerow([year,  num]) 

return  response 


• El  codigo  y los  comentarios  deberfan  ser  bastante  claros,  pero  hay  unas  pocas 
cosas  que  merecen  mention  especial: 

• Se  le  da  a la  respuesta  el  tipo  MIME  text/ csv  (en  lugar  del  tipo  predeterminado 
text/html).  Esto  le  dice  a los  navegadores  que  el  documento  es  un  fichero  CSV. 

• La  respuesta  obtiene  una  cabecera  Content-Disposition  adicional,  la  cual 
contiene  el  nombre  del  fichero  CSV.  Esta  cabecera  (bueno,  la  parte  “adjunta”) 
le  indicara  al  navegador  que  solicite  la  ubicacion  donde  guardara  el  fichero 
(en  lugar  de  simplemente  mostrarlo).  El  nombre  de  fichero  es  arbitrario; 
llamalo  como  quieras.  Sera  usado  por  los  navegadores  en  el  cuadro  de  dialogo 
“Guardar  como...” 

• Usar  el  API  de  generacion  de  CSV  es  sencillo:  basta  pasar  response  como 
primer  argumento  a csv. writer.  La  funcion  csv. writer  espera  un  “objeto  de  tipo 
fichero”,  y los  objetos  de  tipo  HttpResponse  se  ajustan  a ello. 

• Por  cada  fila  en  el  fichero  CSV,  invocamos  a writer.writerow,  pasandole  un 
objeto  iterable  como  una  lista  o una  tupla. 

• El  modulo  CSV  se  encarga  de  poner  comillas  por  ti,  asi  que  no  tendras  que 
preocuparte  por  escapar  caracteres  en  las  cadenas  que  tengan  comillas  o 
comas  en  su  interior.  Limitate  a pasar  la  information  a writerow(),  que  hara  lo 
correcto. 

Este  es  el  patron  general  que  usaras  siempre  que  necesites  retornar  contenido  no 
HTML:  crear  un  objeto  HttpResponse  de  respuesta  (con  un  tipo  MIME  especial), 
pasarselo  a algo  que  espera  un  fichero,  y luego  devolver  la  respuesta. 

Veamos  unos  cuantos  ejemplos  mas. 
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Generar  PDF's  en  Django 

El  Formato  Portable  de  Documentos  (PDF,  por  Portable  Document  Format)  es  un 
formato  desarrollado  por  Adobe  que  es  usado  para  representar  documentos 
imprimibles,  completos  con  formato  perfecto  hasta  un  nivel  de  detalle  medido  en 
pixels,  tipografias  empotradas  y graficos  de  vectores  en  2D.  Puedes  pensar  en  un 
documento  PDF  como  el  equivalente  digital  de  un  documento  impreso; 
efectivamente,  los  PDF's  se  usan  normalmente  cuando  se  necesita  entregar  un 
documento  a alguien  para  que  lo  imprima. 

Puedes  generar  PDF's  facilmente  con  Python  y Django  gracias  a la  excelente 
biblioteca  open  source  ReportFab  http://www.reportlab.org/rl_toolkit.html).  La 
ventaja  de  generar  licheros  PDF's  dinamicamente  es  que  puedes  crear  PDF's  a 
medida  para  diferentes  propositos  - supongamos,  para  diferentes  usuarios  u 
diferentes  contenidos. 

Por  ejemplo,  hemos  usado  Django  y ReportLab  en  KUSports.com  para  generar 
programas  de  torneos  de  la  NCAA  personalizados,  listos  para  ser  impresos. 

Instalar  ReportLab 

Antes  de  que  puedas  generar  algun  PDF,  necesitas  instalar  ReportLab.  Esto  es 
usualmente  muy  simple:  solo  descarga  e instala  la  biblioteca  desde 
® http:  / /www.reportlab.org/ downloads.html. 

La  guia  del  usuario  (naturalmente  disponible  en  formato  PDF)  la  puedes 
encontrar  en  (§)  http://www.reportlab.org/rsrc/userguide.pdf,  contiene  instrucciones 
de  instalacion  adicionales. 

Si  estas  usando  una  distribution  moderna  de  Linux,  podrias  desear  comprobar 
con  la  utilidad  de  manejo  de  paquetes  de  software  antes  de  instalar  ReportLab.  La 
mayoria  de  los  repositorios  de  paquetes  ya  incluyen  ReportLab.  Aunque  simplemente 
Puedes  utilizarpip  install  reportlab. 

Prueba  tu  instalacion  importando  la  misma  en  el  interprete  interactivo  Python: 

»>  import  reportlab 
»> 

Si  ese  comando  no  lanza  ningun  error,  la  instalacion  funciono. 

Vistas  que  producen  PDF's  en  Django 


Del  mismo  modo  que  CSV,  la  generacion  de  PDF's  en  forma  dinamica  con  Django  es 
sencilla  porque  la  API  ReportLab  actua  sobre  objetos  de  forma  similar  a como  lo  hace 
con  ficheros  {file-like segun  la  jerga  Python). 

A continuation  un  ejemplo  “Flola  Mundo”: 


from  reportlab. pdfgen  import  canvas 
from  django.http  import  HttpResponse 
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def  hola_pdf(request): 

# Crea  un  objeto  HttpResponse  con  las  cabeceras  del  PDF  correctas. 

response  = HttpResponse(content_type='application/pdf) 

# Abre  el  PDF  en  la  ventana  del  navegador 

#response['Content-Disposition']  = 'filename-'archivo.pdf'" 

# inicia  el  cuadro  de  dialogo  "abrir  con:" 

response['Content-Disposition']  = 'attachment;  filename=hello.pdf 

# Crea  el  archivo  PDF,  usando  el  objeto  response  como  un  "archivo". 
p = canvas. Canvas(response) 

# Dibuja  cosas  en  el  PDF.  Aqui  se  genera  el  PDF.  Consulta  la 

# documentation  para  obtener  una  lista  completa  de  funcionalidades. 

p.roundRect(0,  750,  694,  120,  20,  stroke=0,  fill=l) 
p.setFillColorRGB(0,l,0) 

# La  fuente  y el  tamano 

p.setFont('Times-Bold',28) 

p.drawString(50,  800,  "Bienvenidos  a Django") 

p.setFont('Times-Roman',  12) 

p.drawString(250,  780,  "Hola  mundo") 

p.setFont('Times-Bold',150) 

p.setFillColorRGB(0,0,0) 

p.drawString(70,  400,  "Django") 

# Cierra  el  objeto  PDF  limpiamente  y termina. 
p.showPage() 

p.save() 

return  response 


El  codigo  y los  comentarios  deberian  explicarse  por  si  mismos,  pero  son 
necesarias  algunas  notas  adicionales: 

Usamos  el  tipo  MIME  application/pdf.  Esto  le  indica  al  navegador  que  el 
documento  es  un  fichero  PDF  y no  un  flchero  E1TML.  Si  no  incluyes  esta  information, 
los  navegadores  web  probablemente  interpretaran  la  respuesta  como  E1TML,  lo  que 
resultara  en  jeroglificos  en  la  ventana  del  navegador. 

La  respuesta  obtiene  una  cabecera  Content-Disposition  adicional,  la  cual 
contiene  el  nombre  del  archivo  PDF.  Este  nombre  es  arbitrario:  llamalo  como 
quieras.  Solo  sera  usado  para  abrir  el  cuadro  de  dialogo  en  el  navegador  “Guardar 
como...” 

En  el  ejemplo  le  agregamos  attachment  a la  respuesta  de  la  cabecera  Content 
Disposition  al  nombre  del  archivo.  Esto  fuerza  a los  navegadores  Web  a presentar  una 
ventana  de  dialogo /confirmation  para  manipular  el  documento  por  defecto  usando 
un  programa  externo,  sin  embargo  si  dejamos  en  bianco  attachment  el  navegador 
manipulara  el  PDF  usando  cualquier  plugin  que  haya  sido  configurada  para  manejar 
este  tipo  de  archivos  dentro  del  navegador,  el  codigo  es  el  siguiente: 

response['Content-Disposition']  = 'filename-'archivo.pdf" 

Interactuar  con  la  API  ReportLab  es  sencillo:  solo  pasa  response  como  el  primer 
argumento  a canvas. Canvas.  La  clase  Canvas  espera  un  objeto  tipo  archivo,  por  lo 
que  los  objetos  ElttpResponse  se  ajustaran  a la  norma. 

Todos  los  metodos  de  generation  de  PDF  subsecuentes  son  llamados  pasandoles 
el  objeto  PDF  (en  este  caso  p),  no  response. 

Finalmente,  es  importante  llamar  a los  metodos  showPage()  y save()  del  objeto 
PDF  (de  otra  manera  obtendras  un  fichero  PDF  corrupto). 
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PDF's  mas  complejos 

Si  estas  creando  un  documento  PDF  complejo  considera  usar  la  biblioteca  io  como 
un  lugar  de  almacenamiento  temporal  para  tu  fichero  PDF.  Esta  biblioteca  provee 
una  interfaz  para  tratar  con  archivos  tipo  objetos  muy  eficientemente. 

En  el  siguiente  ejemplo,  obtenemos  datos  directamente  de  la  base  de  datos,  que 
creamos  en  los  capitulos  anteriores  y los  usamos  para  crear  un  PDF  sencillo  usando 
el  modulo  io  de  Python. 


biblioteca/views .py 


from  io  import  ByteslO 
from  reportlab.pdfgen  import  canvas 
from  django.http  import  HttpResponse 
from  biblioteca.models  import  Libro 

def  convertir_pdf(request,  pk): 

# Obtenemos  un  queryset,  para  un  determinado  libro  usando  pk. 
try: 

libro  = Libro. objects. get(id=pk) 

except  ValueError:  # Si  no  existe  llamamos  a "pagina  no  encontrada". 
raise  Http404() 

# Creamos  un  objeto  HttpResponse  con  las  cabeceras  del  PDF  correctas. 

response  = HttpResponse(content_type- application/pdf) 

# Nos  aseguramos  que  el  navegador  Io  abra  directamente. 

response['Content-Disposition']  = 'filename-'archivo.pdf'" 
buffer  = ByteslO() 

# Creamos  el  objeto  PDF,  usando  el  objeto  ByteslO  como  si  fuera  un  "archivo". 
p = canvas. Canvas(buffer) 

# Dibujamos  cosas  en  el  PDF.  Aquf  se  genera  el  PDF. 

# Consulta  la  documentacion  para  una  lista  completa  de  funcionalidades. 

p.roundRect(0,  750,  694,  120,  20,  stroke=0,  fill=l) 

p.setFont('Times-Bold',32) 

p.setFillColorRGB(l,l,l) 

p.drawString(100,  800,  str(libro.titulo))#Obtenemos  el  titulo  de  un  libro  y la  portada. 
p.drawlmage(str(libro.portada.url),  100,  100,  width=400,  height=600) 

# mostramos  y guardamos  el  objeto  PDF. 

p.showPage() 

p.save() 

# Traemos  el  valor  del  bufer  ByteslO  y devolvemos  la  respuesta. 

pdf  = buffer. getvalue() 

# Cerramos  el  bufer 

buffer.  close() 
response.write(pdf) 
return  response 


Ahora  solo  enlazamos  la  vista  a la  ULRconf  asi: 


Urls .py 


from  django.conf.urls  import  url 
from  biblioteca  import  views 
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urlpatterns  =[ 

url(r'Aconvertir-pdf/(?P<pk>[0-9]+)/$',  views. convertir_pdf,  name- convertir-pdf), 

j 


Otras  posibilidades 

Hay  inflnidad  de  otros  tipos  de  contenido  que  puedes  generar  en  Python.  Aqui 
tenemos  algunas  otras  ideas  y las  bibliotecas  que  podrias  usar  para  implementarlas: 

• Archivos  ZIP:  La  biblioteca  estandar  de  Python  contiene  el  modulo  zipfile, 
que  puede  escribir  y leer  ficheros  comprimidos  en  formato  ZIP.  Puedes  usarla 
para  guardar  ficheros  bajo  demanda,  o quizas  comprimir  grandes 
documentos  cuando  lo  requieran.  De  la  misma  manera  puedes  generar 
ficheros  en  formato  TAR  usando  el  modulo  de  la  biblioteca  estandar  tarfile. 

■ Imagenes  Dinamicas:  Biblioteca  Python  de  procesamiento  de  Imagenes 
(Python  Imaging  Library,  PIL;  (?)  http://www.pythonware.com/products/pil/) 
es  una  herramienta  fantastica  para  producir  imagenes  (PNG,  JPEG,  GIF,  y 
muchas  mas).  Puedes  usarla  para  escalar  automaticamente  imagenes  para 
generar  miniaturas,  agrupar  varias  imagenes  en  un  solo  marco  e incluso 
realizar  procesamiento  de  imagenes  directamente  en  la  web. 

■ Ploteos  y Graficos:  Existe  un  numero  importante  de  increiblemente  potentes 
bibliotecas  de  Python  para  Ploteo  y Graficos,  que  se  pueden  utilizar  para 
generar  mapas,  dibujos,  ploteos  y graficos.  Es  imposible  listar  todas  las 
bibliotecas,  asi  que  resaltamos  algunas  de  ellas: 

o matplotlib  ((?)  http://matplotlib.sourceforge.net/)  puede  usarse  para 
generar  ploteos  de  alta  calidad  al  estilo  de  los  generados  con  MatLab  o 
Mathematica. 

o pygraphviz  ((?)  https://networkx.lanl.gov/wiki/pygraphviz),  una  interfaz 
con  la  herramienta  Graphviz  (http://graphviz.org/),  puede  usarse  para 
generar  diagramas  estructurados  de  grafos  y redes. 

En  general,  cualquier  biblioteca  Python  capaz  de  escribir  en  un  fichero  puede  ser 
utilizada  dentro  de  Django.  Las  posibilidades  son  realmente  interminables. 

Ahora  que  hemos  visto  lo  basico  de  generar  contenido  no-HTML,  avancemos  al 
siguiente  nivel  de  abstraction.  Django  incluye  algunas  herramientas  agradables  e 
ingeniosas  para  generar  cierto  tipo  de  contenido  no-HTML. 

El  Framework  de  Feeds  de  Sindicacion 

Django  incluye  un  framework  para  la  generation  y sindicacion  de  feeds  de  alto  nivel 
que  permite  crear  feeds  RSS  y Atom  de  manera  sencilla. 


Nota:  RSS  y Atom  son  formatos  basados  en  XML  que  se  puede  utilizar  para 
actualizar  automaticamente  los  “feeds”  con  el  contenido  de  tu  sitio.  Lee  mas  sobre 
RSS  en  (?)  http://www.whatisrss.com/,  y obten  information  sobre  Atom  en 
(?)  http:  / / www.atomenabled.org/ . 

Para  crear  cualquier  feed  de  sindicacion,  todo  lo  que  necesitas  hacer  es  escribir  una 
pequena  clase  Python.  Puedes  crear  tantos  feeds  como  desees. 
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El  framework  de  generacion  de  feeds  de  alto  nivel  es  una  vista  enganchada  a 
/feeds/  por  convencion.  Django  usa  el  final  de  la  URL  (todo  lo  que  este  despues  de 
/feeds/)  para  determinar  que  feed  retornar. 

Para  crear  un  feed,  necesitas  escribir  una  clase  Feed  y hacer  referencia  a la  misma 
en  tu  URLconf  (Consulta  los  capitulos  3 y 8 para  mas  information  sobre  URLconfs). 

Initialization 

Para  activar  los  feeds  de  sindicacion  en  tu  sitio  Django,  agrega  lo  siguiente  en  tu 
URLconf: 

from  biblioteca.feeds  import  UltimosLibros 
urlpatterns  =[ 

url(r'Afeeds/$',  UltimosLibros()), 

] 


Esa  linea  le  indica  a Django  que  use  el  framework  RSS  para  captar  las  URLs  que 
comienzan  con  "feeds/".  (Puedes  cambiar  "feeds/"  por  algo  que  se  adapte  mejor  a tus 
necesidades). 

Debes  tener  en  cuenta  que: 

• El  feed  es  representado  por  la  clase  UltimosLibros  el  cual  por  convencion  y 
claridad  residira  en  un  nuevo  archivo  llamado  feeds. py,  en  el  mismo  nivel  que 
models.py,  aunque  puede  residir  en  cualquier  parte  del  arbol  de  codigo. 

• La  clase  Feed  debe  ser  una  subclase  de  django.contrib.syndication.feeds.Feed. 

• Una  vez  que  este  configurada  la  URL,  necesitas  definir  la  propia  clase  Feed. 
Puedes  pensar  en  una  clase  Feed  como  un  tipo  de  clase  generica. 

Una  clase  Feed  es  una  simple  clase  Python  que  representa  un  feed  de  sindicacion. 
Un  feed  puede  ser  simple  (p.  ej.  “noticias  del  sitio”,  o una  lista  de  las  ultimas  entradas 
del  blog)  o mas  complejo  (p.  ej.  mostrar  todas  las  entradas  de  un  blog  en  una 
categoria  en  particular,  donde  la  categoria  es  variable). 

Un  Feed  simple 

Siguiendo  con  el  modelo  creado  en  los  capitulos  anteriores,  veamos  ahora  como 
crear  un  simple  feed,  que  muestre  los  ultimos  cinco  libros  agregados  a nuestra 
aplicacion  biblioteca. 

Empecemos  por  escribir  la  clase: 


biblioteca/feeds .py 


from  django.contrib. syndication. views  import  Feed 
from  django.core.urlresolvers  import  reverse 
from  django. utils  import  feedgenerator 

from  biblioteca.models  import  Libro 
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class  UltimosLibrosFeed(Feed): 

# FEED  TYPE  - Opcional,  Este  debe  ser  una  subclase  de  la  clase 

# django. utils. feedgenerator.SyndicationFeed.  Este  designa 

# el  tipo  de  feed  a usar:  RSS  2.0,  Atom  1.0,  etc.  Si  no  se 

# especifica  el  tipo  de  feed  (feed_type),  se  asumira  que  el  tipo 

# es  RSS  2.0.  Este  debe  aparecer  en  una  clase,  no  en  una  instancia  de 

# una  clase. 

feed_type  = feedgenerator.Rss201rev2Feed 

title  = "Feed  libros  publicados" 
link  = "/ultimos-libros/" 

description  = "Ultimos  libros  publicados  en  la  biblioteca  digital." 
def  items(self): 

iiiiii 

Retorna  una  lista  de  items  para  publicar  en  este  feed. 

iiiiii 

return  Libro. objects. order_by('-fecha_publicacion')[::  ] 
def  item_title(self,  item): 

IIIIII 

Toma  un  item,  retornado  por  el  metodo  items(),  y devuelve  los  item's 
del  tftulo  como  cadena  normales  Python. 

iiiiii 

return  item.titulo 
def  item_description(  elf,  item): 

iiiiii 

Toma  un  item,  retornado  por  el  metodo  items(),  y devuelve  los  item's 
con  una  descripcion  en  forma  de  cadena  normal  de  Python. 

iiiiii 

return  item. descripcion 
def  item_link(self,  item): 

iiiiii 

Toma  un  item,  retornado  por  el  metodo  items(),  y devuelve  la  URL  de 
los  item's.  Es  usado  solo  si  el  modelo  no  tiene  un  metodo 
get_absolute_url()  definido. 

mill 

return  reverse('detalle-libro',  args=[item.pk]) 
def  item_enclosure_url(  elf,  item): 

iiiiii 

Toma  un  item,  retornado  por  el  metodo  items(),  y devuelve  los  item's 
adjuntos  en  la  URL. 

mm 

return  item.portada.url 
def  item_enclosure_length(self,  item): 

mm 

Toma  un  item,  retornado  por  el  metodo  items(),  y devuelve  el  largo 
de  los  item's  adjuntos. 

mm 

return  item.portada.size 
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item_enclosure_mime_type  = "image/jpeg"  # Definimos  manualmente  el  tipo  MIME. 


Para  conectar  la  URL  con  el  feed,  usamos  una  instancia  de  un  objeto  Feed  en  la 
URLconf.  Por  ejemplo: 


urls .py 


from  django.conf.urls  import  url 

from  biblioteca.feeds  import  UltimosLibrosFeed 

urlpatterns  = [ 

# ... 

url(r'Afeeds/$',  UltimosLibrosFeed()), 

# ... 

j 


Las  cosas  importantes  a tener  en  cuenta  son: 

• La  clase  Feed  es  una  subclase  de  django.contrib.syndication.views.Feed. 

• title,  link,  y description  corresponden  a los  elementos  RSS  estandar  <title>, 
<link>,  y <description>  respectivamente. 

• items 0 es  simplemente  un  metodo  que  retorna  una  lista  de  objetos  que 
deben  incluirse  en  el  feed  como  elementos  <item>.  Aunque  este  ejemplo 
retorna  objetos  Newsltem  usando  la  API  de  base  de  datos  de  Django,  no  es  un 
requerimiento  que  items ()  deba  retornar  instancias  de  modelos. 

• Obtienes  unos  pocos  bits  de  funcionalidad  “gratis”  usando  los  modelos  de 
Django,  pero  items()  puede  retornar  cualquier  tipo  de  objeto  que  desees. 

Flay  solamente  un  paso  mas.  En  un  feed  RSS,  cada  <item>  posee  <title>,  <link>,  y 
<description>.  Por  lo  que  es  necesario  decide  al  framework  que  datos  debe  poner  en 
cada  uno  de  los  elementos. 

• Para  especificar  el  contenido  de  <title>  y <description>,  Django  trata  de  llamar 
a los  metodos  item_title()  e item_description()  en  la  clase  Feed.  Estos  son 
pasados  como  simples  parametros  item,  el  cual  es  el  objeto  en  si  mismo. 
Tambien  estos  metodos  son  opcionales;  por  defecto  la  representation 
Unicode  del  objeto  es  usado  en  ambos. 

• Para  especificar  contenido  con  algun  formato  en  especifico  para  <title>  y 
<description>,  crea  plantillas  Django  (ver  capitulo  4)  Puedes  especificar  la 
ruta  con  los  atributos  title_template  y description_template  en  la  clase  Feed. 
El  sistema  RSS  rende  riza  dicha  plantilla  por  cada  item,  pasandole  dos 
variables  de  contexto  para  plantillas: 

{{ obj}}:  El  objeto  actual  (uno  de  los  tantos  que  retorna  en  items (). 

{{  site  }}:  Un  objeto  django. models. core.sites. Site  representa  el  sitio  actual. 
Esto  es  util  para  {{ site.domain  }}  o {{ site. name  }}. 

Si  no  creas  una  plantilla  para  el  titulo  o la  description,  el  framework  utilizara 
la  plantilla  por  omision  "{{  obj  }}"  - exacto,  la  cadena  normal  de 
representation  del  objeto. 
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Tambien  puedes  cambiar  los  nombres  de  estas  plantillas  especificando 
titie_template  y description_template  como  atributos  de  tu  clase  Feed. 

• Para  especificar  el  contenido  de  <link>,  hay  dos  opciones.  Por  cada  Item  en 
items(),  Django  primero  tratara  de  ejecutar  el  metodo  get_absolute_url() 
en  dicho  objeto.  Si  dicho  metodo  no  existe,  entonces  trata  de  llamar  al 
metodo  item_link()  en  la  clase  Feed,  pasandole  un  unico  parametro,  item, 
que  es  el  objeto  en  si  mismo. 

Ambos  metodos:  get_absolute_url()  y item_link()  deben  retornar  la  URL  del 
item  como  una  cadena  normal  de  Python. 

Tambien  es  posible  pasarle  informacion  adicional  a title  y a description  en  las 
plantillas,  si  es  que  necesitas  suministrar  mas  informacion  a las  dos  variables 
anteriores.  Para  hacerlo  solo  necesitas  implementar  el  metodo  get_context_data  en  la 
subclase  Feed. 

Por  ejemplo: 

from  django.contrib. syndication. views  import  Feed 
from  biblioteca.models  import  Libro 

class  UltimosLibrosFeed(Feed): 

# NOMBRES  PLANTILLAS  - Opcionales.  Estas  deben  de  ser  cadenas  de  texto 

# que  representan  el  nombre  de  las  plantillas  que  Django  usara  para 

# renderizar  el  titulo  y la  descripcion  del  los  items  del  Feed. 

# Ambos  son  opcionales.  Si  no  se  especifica  una  plantilla,  se  usara 

# el  metodo  item_title()  o item_description()  en  su  lugar. 

title  = "Mis  Libras"  # Hard-coded  titulo. 

Iink=  "/libras/" 

description_template  = "feeds/libros.html"  # La  plantilla 
def  items(self): 

linn 

Retorna  una  lista  de  items  para  publicar  en  este  feed. 

Illlll 

return  Libro. objects. order_by('-fecha_publicacion')[:5] 
def  get_context_data(self,  **kwargs): 

linn 

Toma  la  peticion  actual  y los  argumentos  de  la  URL,  y 
devuelve  un  objeto  que  representa  este  feed.  Levanta  una 
excepcion  del  tipo  django. core. exceptions. ObjectDoesNotExist 
si  existe  algun  error. 

■ uni 

context  = (UltimosLibrosFeed,  !f).get_context_data(**kwargs) 
context['foo']  = 'bar' 

return  context 


Y en  la  plantilla  algo  como  esto: 
{{ foo  }}:  {{  obj. description  }} 
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Este  metodo  sera  llamado  una  vez  por  cada  item  en  la  lista  de  libros  devuelta  por 
items ()  con  los  siguientes  argumentos  clave: 

1.  item  El  actual  item.  Por  razones  de  compatibilidad,  el  nombre  de  esta  variable 
de  contexto  es  {{  obj }}. 

2.  obj  El  objeto  devuelto  por  el  metodo  get_object()-  Por  defecto  este  no  es 
expuesto  en  las  plantillas  para  evitar  confusion  con  get_object().  (ver  arriba), 
pero  se  puede  usar  en  la  implementacion  de  el  metodo  get_context_data(). 

3.  site  El  sitio  actual,  descrito  anteriormente. 

4.  request  La  peticion  actual  o request. 

Como  puedes  ver  el  comportamiento  de  get_context_data()  es  muy  similar  al  de 
las  vistas  genericas  - solo  llamas  a la  super  claseO  para  extraer  datos  del  contexto  de 
la  clase  padre,  agregas  datos  y devuelves  el  diccionario  modificado. 


Un  Feed  mas  complejo 

El  framework  tambien  permite  la  creacion  de  feeds  mas  complejos  mediante  el  uso 
de  parametros. 

Por  ejemplo,  http://chicagocrime.org  ofrece  un  feed  RSS  de  los  crimenes  recientes 
de  cada  departamento  de  policia  en  Chicago.  Serfa  tonto  crear  una  clase  Feed 
separada  por  cada  departamento;  esto  puede  violar  el  principio  “No  te  repitas  a ti 
mismo”  (DRY,  por  “Do  not  repeat  yourself”)  y crearia  acoplamiento  entre  los  datos  y 
la  logica  de  programacion. 

En  su  lugar,  el  framework  de  feeds  de  sindicacion  te  permite  crear  feeds  genericos 
que  retornan  items  basados  en  la  information  de  la  URL  del  feed. 

En  chicagocrime.org,  los  feed  por  departamento  de  policia  son  accesibles 
mediante  URLs  como  estas: 

• /beats/613/rss/ : Retorna  los  crimenes  mas  recientes  para  el  departamento 
0613 

• /beats/ 1424 /rss/:  Retorna  los  crimenes  mas  recientes  para  el 

departamento  1424 

Estas  funcionan  con  una  URLconf  parecida  a esta: 
url(r'Abeats/(?P<beatJd>[0-9]+)/rss/$',  BeatFeed()), 

El  slug  aqui  es  "beats".  El  framework  de  sindicacion  ve  las  partes  extra  en  la  URL 
tras  el  slug  - 0613  y 1424  - y te  provee  un  gancho  ( hook]  para  que  le  indiques  que 
significa  cada  uno  de  esas  partes  y como  influyen  en  los  items  que  seran  publicados 
en  el  feed. 

Tal  como  en  una  vista,  los  argumentos  en  la  URL  son  pasados  mediante  el  metodo 
get_object()  junto  con  el  objeto  de  la  peticion. 

Un  ejemplo  aclarara  esto.  Este  es  el  codigo  para  los  feeds  por  departamento: 


from  django.contrib.syndication.views  import  FeedDoesNotExist 
from  django. shortcuts  import  get_object_or_404 


278 


CAPITULO  13  ■GENERACION  DE  CONTENIDOS  NO  HTML 


class  BeatFeed(Feed): 

description_template  = 'feeds/beat_description.htmr 

def  get_object(self,  request,  beatjd): 

return  get_object_or_404(Beat,  pk=beat_id) 

def  title(self,  obj): 

return  "Police  beat  central:  Crimes  for  beat  %s"  % obj. beat 

def  link(self,  obj): 

return  obj.get_absolute_url() 

def  description(self,  obj): 

return  "Crimes  recently  reported  in  police  beat  %s"  % obj. beat 
def  items(self,  obj): 

return  Crime. objects. filter(beat=obj).order_by(-crime_date')[:3Q] 


Para  generar  los  feed's  <title>,  <link>  y <description>,  Django  usa  los  metodos 
titleO,  link()  y description().  En  el  ejemplo  anterior,  estos  eran  atributos  simples  de 
una  clase,  pero  este  ejemplo  ilustra  que  estos  pueden  ser  tanto  metodos  o cadenas. 
Por  cada  title,  link  y description, 

Django  sigue  el  siguiente  algoritmo. 

1.  Primero  trata  de  llamar  al  metodo,  pasando  el  argumento  obj,  donde  obj  es  el 
objeto  retornado  por  get_object(). 

2.  Si  eso  falla,  trata  de  llamar  al  metodo  sin  argumentos. 

3.  Si  eso  falla,  usa  los  atributos  de  clase. 

Nota  que  items()  en  el  ejemplo  anterior,  tambien  toma  como  argumento  a obj.  El 
algoritmo  para  items  es  el  mismo  que  se  describe  en  el  paso  anterior  - primero 
prueba  items  (obj),  despues  items  (),  y flnalmente  un  atributo  de  clase  items  (que  debe 
ser  unalista). 

Estamos  usando  una  plantilla  muy  simple  para  las  descripciones  de  los  items, 
como  esta: 

{{ obj. description  }} 


Especificar  el  tipo  de  Feed 


Por  omision,  el  framework  de  feeds  de  sindicacion  produce  RSS  2.0.  Para  cambiar 
eso,  agrega  un  atributo  feed_type  a la  clase  Feed: 

from  django. utils. feedgenerator  import  AtomlFeed 

class  MiFeed(Feed): 

feed_type  = AtomlFeed 
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Observa  que  asignas  como  valor  de  feed_type  una  clase,  no  una  instancia.  Los 
tipos  de  feeds  disponibles  actualmente  se  muestran  en  la  siguiente  tabla. 


Clase  Feed 

Formato 

django.  utils.  feedgenerator.Rss201rev2Feed 
django. utils. feedgenerator.RssUserland091Feed 
django.utils.feedgenerator.AtomlFeed 

RSS2.01  (pordefecto) 

RSS0.91 

Atom  1.0 

Tabla  13-1.  Tipos  de  Feeds  disponibles  en  Django. 


Adjuntos 

Para  especificar  archivos  adjuntos  o enclosures  (p.  ej.  recursos  multimedia  asociados 
al  item  del  feed  tales  como  feeds  de  podcasts  MP3,  imagenes),  usa  los  metodos 
item_enclosure_url,  item_enclosure_length,  e item_enclosure_mime_type. 

Por  ejemplo: 


biblioteca/feeds .py 


from  django.contrib. syndication. views  import  Feed 
from  biblioteca.models  import  Libro 

class  UltimosLibrosConAdjuntos(Feed): 
title  = "Ultimas  portadas  de  Libros" 
link  = "/feeds/ejemplo-con-adjuntos/" 

def  items(self): 

return  Libro. objects. all()[:30] 

def  item_enclosure_url(  alf,  item): 
return  item.portada.url 

def  item_enclosure_length(self,  item): 
return  item.portada.size 

item_enclosure_mime_type  = "image/jpeg"  # Definimos  un  mime-type 


Esto  asume,  por  supuesto  que  estamos  usando  el  modelo  Libro  el  cual  contiene  un 
campo  llamado  portada  (que  es  una  imagen),  al  cual  se  accede  a su  URL  mediante 
portada.url  y mediante  portada.size  obtenemos  el  tamano  en  bytes. 

Yla  url  queda  como  sigue: 


urls .py 


from  django.conf.urls  import  url 

from  biblioteca.feeds  import  UltimosLibrosConAdjuntos 

urlpatterns  = [ 

# ... 
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url(r'Afeeds/adjuntos/$',  UltimosLibrosConAdjuntos()), 

# ... 

] 


Lenguage 

Los  Feeds  creados  por  el  framework  de  sindicacion  incluyen  automaticamente  la 
etiqueta  <language>  (RSS  2.0)  o el  atributo  xmldang  apropiados  (Atom).  Esto  viene 
directamente  de  tu  variable  de  configuracion  LANGUAGE_CODE. 

URLs 

El  metodo /atributo  link  puede  retornar  tanto  una  URL  absoluta  (p.  ej.  "/blog/")  como 
una  URL  con  el  nombre  completo  de  dominio  y protocolo  (p.  ej. 
"http://www.example.com/blog/").  Si  link  no  retorna  el  dominio,  el  framework  de 
sindicacion  insertara  el  dominio  del  sitio  actual,  acorde  a la  variable  de  configuracion 
SITEJD. 

Los  feeds  Atom  requieren  un  clink  rel="self">  que  define  la  ubicacion  actual  del 
feed.  El  framework  de  sindicacion  completa  esto  automaticamente,  usando  el 
dominio  del  sitio  actual  acorde  a la  variable  de  configuracion  SITEJD. 

Publicar  feeds  Atom  y RSS  conjuntamente 

Algunos  desarrolladores  prefleren  ofrecer  ambas  versiones  Atom  /RSS  de  sus  feeds. 
Esto  es  simple  de  hacer  con  Django:  solamente  crea  una  subclase  de  tu  clase  feed  y 
asigna  a feedjype  un  valor  diferente.  Luego  actualiza  tu  URLconf  para  agregar  una 
version  extra.  Aqui  un  ejemplo  usando  completo: 


bibliteca/ feeds .py 


from  django.contrib. syndication. views  import  Feed 
from  django. utils. feedgenerator  import  AtomlFeed 

from  biblioteca.models  import  Libro 

class  UltimosLibrosFeed(Feed): 
title  = "Feed  libros  publicados" 
link  = "/libros/" 

description  = "Ultimos  libros  publicados  en  la  biblioteca  digital." 
def  items(self): 

return  Libro. objects. order_by('-fecha_publicacion')[:5] 

class  UltimosLibrosAtom(UltimosLibrosFeed): 

feedjype  = AtomlFeed 

subtitle  = UltimosLibrosFeed.  description 


Y este  es  el  URLconf  asociada  a cada  entrada: 


urls .py 


from  django. conf.urls  import  url 

from  biblioteca.feeds  import  UltimosLibrosFeed,  UltimosLibrosAtom 
urlpatterns  = [ 
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# ... 

url(r'Afeeds/$',  UltimosLibrosFeed()), 
url(r'Aatom/$',  UltimosLibrosAtom()), 

# ... 

]_ 

El  Framework  Sitemap 

Un  sitemap  es  un  fichero  XML  en  tu  sitio  web  que  le  indica  a los  indexadores  de  los 
motores  de  busqueda  cuan  frecuentemente  cambian  tus  paginas,  asi  como  la 
“importancia”  relativa  de  ciertas  paginas  en  relation  con  otras  (siempre  hablando  de 
paginas  de  tu  sitio  Web).  Esta  informacion  ayuda  a los  motores  de  busqueda  a 
indexar  tu  sitio. 

Por  ejemplo,  esta  es  una  parte  del  sitemap  del  sitio  web  de  Django 
(http : / /www.  dj  angopro  j ect.  co  m / sitemap  .xml) : 

<?xml  version="1.0"  encoding="UTF-8"?> 

<urlset  xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> 

<url> 

<loc>http://www.djangoproject.com/documentation/</loc> 

<changefreq>weekly</changefreq> 

<priority>0.5</priority> 

</url> 

<url> 

<loc>http://www.djangoproject.com/documentation/0_90/</loc> 

<changefreq>never</changefreq> 

<priority>0.  l</priority> 

</url> 

</urlset> 


Para  mas  informacion  sobre  sitemaps,  consulta  ® http://www.sitemaps.org/. 

El  framework  sitemap  de  Django  automatiza  la  creation  de  este  fichero  XML  si  lo 
indicas  expresamente  en  el  codigo  Python.  Para  crear  un  sitemap,  debes 
simplemente  escribir  una  clase  Sitemap  y hacer  referencia  a la  misma  en  tu  URLconf. 


Instalacion 

Para  instalar  la  aplicacion  sitemap,  sigue  los  siguientes  pasos: 

1.  Agrega  'django.contrib. sitemaps'  a tu  variable  de  configuracion 
INSTALLED_APPS. 

2.  Asegurate  de  que  'django.template.loaders.app_directories. Loader'  esta  en  tu 
variable  de  configuracion  TEMPLATE_LOADERS.  Para  que  la  aplicacion 
sitemap  encuentre  las  plantillas  que  necesita  para  funcionar. 

3.  Asegurate  de  que  tienes  instalado  el  framework  sites 

La  aplicacion  sitemap  no  instala  tablas  en  la  base  de  datos.  La  unica  razon  de  que 
este  en  INSTALLED_APPS  es  que  el  cargador  de  plantillas  Loader!)  pueda  encontrar 
las  plantillas  incluidas. 
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Inicializacion 

Para  activar  la  generation  del  sitemap  en  tu  sitio  Django,  agrega  la  siguiente  linea  a tu 
URLconf: 

from  django.contrib. sitemaps. views  import  sitemap 
urlpatterns  =[ 

url(r'Asitemap\.xml$',  sitemap,  {'sitemaps':  sitemaps}, 
name-django.contrib.  sitemaps,  views,  sitemap') 

] 


Esta  linea  le  dice  a Django  que  construya  un  sitemap  cuando  un  cliente  accede  a 
/sitemap  .xml. 

El  nombre  del  fichero  sitemap  no  es  importante,  pero  la  ubicacion  si  lo  es.  Los 
motores  de  busqueda  solamente  indexan  los  enlaces  en  tu  sitemap  para  el  nivel  de 
URL  actual  y anterior. 

Por  ejemplo,  si  sitemap.xml  reside  en  tu  directorio  principal,  el  mismo  puede 
hacer  referencia  a cualquier  URL  en  tu  sitio.  Pero  si  tu  sitemap  reside  en 
/content/sitemap.xml,  solamente  podra  hacer  referencia  a URLs  que  comiencen  con 
/content/. 

La  vista  sitemap  toma  un  argumento  extra:  {'sitemaps':  sitemaps},  sitemaps  debe 
ser  un  diccionario  que  mapee  una  etiqueta  corta  de  section  (p.  ej.  blog  o consulta)  a 
tu  clase  Sitemap  (p.e.,  BlogSitemap  o NewsSitemap). 

Tambien  puede  mapear  una  instancia  de  una  clase  Sitemap  (p.  ej. 
GenericSitemap(alguna_varj)  en  el  mismo  archivo  urls.py. 

Clases  Sitemap 

Una  clase  Sitemap  es  simplemente  una  clase  Python  que  representa  una  “section”  de 
entradas  en  tu  sitemap.  Por  ejemplo,  una  clase  Sitemap  puede  representar  todas  las 
entradas  de  tu  weblog,  y otra  puede  representar  todos  los  eventos  de  tu  calendario. 

En  el  caso  mas  simple,  todas  estas  secciones  se  unen  en  un  unico  sitemap.xml, 
pero  tambien  es  posible  usar  el  framework  para  generar  un  indice  sitemap  que  haga  a 
referencia  ficheros  sitemap  individuales,  uno  por  section  (describiendolo 
sinteticamente). 

Las  clases  Sitemap  debe  ser  una  subclase  de  django.contrib. sitemaps. Sitemap. 
Estas  pueden  residir  en  cualquier  parte  del  arbol  de  codigo. 

Por  ejemplo,  asumamos  que  posees  un  sistema  llamado  biblioteca  (si  haz  seguido 
los  ejemplos  ya  tienes  uno),  con  un  modelo  Autor,  y quieres  que  tu  sitemap  incluya 
todos  los  enlaces  a los  autores. 

Tu  clase  Sitemap  deberia  verse  asi: 


biblioteca/sitemap .py 


from  django.contrib. sitemaps  import  Sitemap 
from  biblioteca.models  import  Autor 

class  SitemapAutores(Sitemap): 
changefreq  = "monthly" 
priority  = 0.5 


def  items(self): 
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return  Autor. objects. all() 

def  lastmod(self,  items): 
return  items. ultimo_acceso 

Y solo  necesitas  enlazar  la  clase  SitemapAutores  a la  URLconf,  asi: 


urls .py 


from  django.conf.urls  import  url 

from  django.contrib. sitemaps. views  import  sitemap 

from  biblioteca.sitemap  import  SitemapAutores 

urlpatterns  =[ 

#... 

url(r'Asitemap\.xml$',  sitemap,  {'sitemaps':  {'sitemaps':  SitemapAutores}}), 

] 


Declarar  un  Sitemap  deberia  verse  muy  similar  a declarar  un  Feed;  esto  es 
justamente  un  objetivo  de  diseno. 

De  forma  similar  a las  clases  Feed,  los  miembros  de  Sitemap  pueden  ser  metodos 
o atributos.  Consulta  la  section  “Un  feed  mas  complejo”  para  obtener  mas 
information  sobre  como  funciona. 

Una  clase  Sitemap  puede  definir  los  siguientes  metodos/atributos: 

• items  (requerido):  Provee  una  lista  de  objetos.  A1  framework  no  le  importa 
que  tipo  de  objeto  sean;  todo  lo  que  le  importa  es  que  los  objetos  sean 
pasados  a los  metodos  location(),  lastmodO,  changefreqO,  y priorityQ. 

• location  (opcional):  Provee  la  URL  absoluta  para  el  objeto  dado.  La  “URL 
absoluta”  significa  una  URL  que  no  incluye  el  protocolo  o el  dominio. 

Estos  son  algunos  ejemplos: 

Bien : '/foo/bar/' 

MaL:  'exampLe.com/foo/bar/' 

MaL : ' http : //exampLe . com/f oo/bar/ ' 

Si  location  no  es  provisto,  el  framework  llamara  al  metodo  get_absolute_url() 
en  cada  uno  de  los  objetos  retornados  por  items (). 

• lastmod  (opcional):  La  fecha  de  “ultima  modification”  del  objeto,  como  un 
objeto  datetime  de  Python. 

• changefreq  (opcional):  Cuan  a menudo  el  objeto  cambia.  Los  valores  posibles 
(segun  indican  las  especificaciones  de  Sitemaps)  son: 

o 'always' 
o 'hourly' 
o 'daily' 
o 'weekly' 
o 'monthly' 
o 'yearly' 
o 'never' 
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• priority  (opcional):  Prioridad  sugerida  de  indexado;  entre  0.0  y 1.0.  La 
prioridad  por  omision  de  una  pagina  es  0.5;  ver  la  documentation  de 
® http://sitemaps.org  para  mas  information  de  como  funciona  priority. 


Accesos  directos 

El  framework  sitemap  provee  un  conjunto  de  clases  para  los  casos  mas  comunes. 
Describiremos  estos  casos  en  las  secciones  a continuation. 

FlatPageSitemap 

La  clase  django.contrib. sitemaps. FlatPageSitemap  apunta  a todas  las  paginas  planas 
definidas  para  el  sitio  actual  y crea  una  entrada  en  el  sitemap.  Estas  entradas  incluyen 
solamente  el  atributo  location  - no  lastmod,  changefreq,  o priority. 

Para  mas  information  sobre  Paginas  Planas  o “flatpages”  consulta  el  capitulo  14. 

GenericSitemap 

La  clase  GenericSitemap  ( Sitemap  Generico)  trabaja  de  forma  bastante  sencilla. 

Para  usarla,  solo  crea  una  instancia  pasandola  en  una  variable  a sitemap  en  forma 
de  diccionario.  El  unico  requerimiento  es  que  el  diccionario  tenga  una  entrada  a un 
queryset.  Tambien  debe  poseer  una  entrada  un  campo  "date_fleld"  que  especifica  un 
campo  fecha  para  los  objetos  obtenidos  del  queryset.  Esto  sera  usado  por  el  atributo 
lastmod  en  el  sitemap  generado.  Tambien  puedes  pasar  argumentos  por  palabras 
clave  ( keyword)  priority  y changefreq  al  constructor  GenericSitemap  para  especificar 
dichos  atributos  para  todas  las  URLs. 

Este  es  un  ejemplo  de  URLconf  parecido  al  anterior,  solo  que  aqui  estamos  usando 
la  clase  generica  GenericSiteMap  usando  el  mismo  modelo  Autor. 


urls .py 


from  django.conf.urls  import  url 

from  django.contrib. sitemaps. views  import  sitemap 

from  django.contrib. sitemaps  import  GenericSitemap 

from  biblioteca.models  import  Autor 

consulta  = { 

'queryset':  Autor. objects. all(),  # Un  queryset 
’date_field':  'ultimo_acceso',  #Un  campo  tipo  fecha 
} 

sitemaps  = { 

'autores':  GenericSitemap(consulta,  priority=0.6,  changefreq=  'always'), 

} 

urlpatterns  =[ 

#... 

url(r'Asitemap\.xml$',  sitemap,  {'sitemaps':  sitemaps:}), 


] 
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Crear  un  mdice  Sitemap 

El  framework  sitemap  tambien  tiene  la  habilidad  de  crear  indices  sitemap  que  hagan 
referencia  a ficheros  sitemap  individuates,  uno  por  cada  section  definida  en  tu 
diccionario  sitemaps. 

Las  unicas  diferencias  de  uso  son: 

■ Usas  dos  vistas  en  tu  URLconf:  django.contrib.sitemaps.views. index  y 
django.contrib.sitemaps.views. sitemap. 

■ La  vista  django.contrib.sitemaps.views. sitemap  debe  tomar  un  parametro  que 
corresponde  a una  palabra  clave,  llamado  section.  Por  ejemplo: 

urlpatterns  =[ 

#... 

url(r'Asitemap\.xml$', 'django.contrib.sitemaps.views. index', 

{'sitemaps':  sitemaps}), 

url(r'Asitemap-(?P<section>.+).xml$',  'django.contrib.sitemaps.views. sitemap', 
{'sitemaps':  sitemaps}) 

] 


Asi  deberian  verse  las  lineas  relevantes  en  tu  URLconf  para  el  ejemplo  anterior. 

Esto  genera  automaticamente  un  fichero  sitemap.xml  que  hace  referencia  a ambos 
ficheros  sitemap-flatpages.xml  y sitemap-autores.xml.  La  clase  Sitemap  y el 
diccionario  sitemaps  no  cambian  en  absoluto. 

Hacer  ping  a Google 


Puedes  desear  hacer  un  “ping”  a Google  cuando  tu  sitemap  cambia,  para  hacerle 
saber  que  debe  reindexar  tu  sitio  Web.  El  framework  provee  una  funcion  para  hacer 
justamente  eso: 

django.contrib.  sitemaps.  ping_google(). 


Nota:  jPrimero  registrate  con  Google! 


El  comando  ping_google()  unicamente  trabaja  si  haz  registrado  tu  sitio  con  Google 
Webmaster  Tools. 

ping_google()  toma  un  argumento  opcional,  sitemap_url,  que  debe  ser  la  URL 
absoluta  de  tu  sitemap  (por  ej.,  '/sitemap.xml').  Si  este  argumento  no  es  provisto, 
ping_google()  tratara  de  generar  un  sitemap  realizando  una  busqueda  reversa  en  tu 
URLconf. 

ping_google()  lanza  la  exception  django.contrib. sitemaps.SitemapNotFound  si  no 
puede  determinar  la  URL  de  tu  sitemap. 

Una  forma  util  de  llamar  a ping_google()  es  desde  el  metodo  save(): 

from  django.contrib. sitemaps  import  ping_google 

class  Libro(models. Model): 

# ... 

def  save(self,  force_insert=  alse,  force_update=  :alse): 
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su  (Libro,  lf).save(force_insert,  force_update) 
try: 

ping_google() 
except  Exception: 

#Por  si  ocurre  una  excepcion 
Pass 

Una  solution  mas  eflciente,  sin  embargo,  seria  llamar  a ping_google()  desde  un 
script  cron  o un  manejador  de  tareas.  La  funcion  hace  un  pedido  HTTP  a los 
servidores  de  Google,  por  lo  que  no  querras  introducir  esa  demora  asociada  a la 
actividad  de  red  cada  vez  que  se  llame  al  metodo  saved. 


Hacer  ping  a Google  mediante  manage.py 

Una  vez  que  la  aplicacion  sitemap  es  agregada  a tu  proyecto,  puedes  hacer  ping  a 
Google  manualmente  usando  el  comando  ping_google  mediante  la  linea  de 
comandos  asi: 

python  manage.py  ping_google  [/sitemap. xml] 


<?,Que  sigue? 

A continuation,  seguiremos  indagando  mas  profundamente  en  las  herramientas 
internas  que  Django  nos  ofrece.  El  capitulo  14  examina  todas  las  herramientas  que 
necesitas  para  proveer  sitios  personalizados:  sesiones,  usuarios,  y autenticacion. 


CAPITULO  14 


Sesiones,  usuarios  e 
inscripciones 

T enemos  que  confesar  algo:  hasta  el  momento  hemos  ignorado  un  aspecto 
absolutamente  importante  del  desarrollo  web.  Hemos  hecho  la  suposicion  de  que  el 
trafico  que  visita  nuestra  web  esta  compuesto  por  una  masa  amorfa  de  usuarios 
anonimos,  que  se  precipitan  contra  nuestras  cuidadosamente  disenadas  paginas. 

Esto  no  es  verdad,  claro.  Los  navegadores  que  consultan  nuestras  paginas  tienen  a 
personas  reales  detras  (la  mayor  parte  del  tiempo,  al  menos).  Este  es  un  hecho 
importantisimo  y que  no  debemos  ignorar:  Lo  mejor  de  Internet  es  que  sirve  para 
conectar  personas,  no  maquinas.  Si  queremos  desarrollar  un  sitio  web  realmente 
competitivo,  antes  o despues  tendremos  que  plantearnos  como  tratar  a las  personas 
que  estan  detras  del  navegador. 

Por  desgracia,  no  es  tan  facil  como  podrfa  parecer.  El  protocolo  HTTP  se  diseno 
especfficamente  para  que  fuera  un  protocolo  sin  estado,  es  decir,  que  cada  peticion  y 
respuesta  esta  totalmente  aislada  de  las  demas.  No  hay  persistencia  entre  una 
peticion  y la  siguiente,  y ninguno  de  los  atributos  de  la  peticion  (direction  IP, 
identiflcador  del  agente,  etc...)  nos  permite  discriminar  de  forma  segura  y consistente 
las  peticiones  de  una  persona  de  las  del  resto. 

En  este  capltulo  aprenderemos  como  solucionar  esta  carencia  de  estados. 
Empezaremos  al  nivel  mas  bajo  {cookies),  e iremos  ascendiendo  hasta  las 
herramientas  de  alto  nivel  que  nos  permitiran  gestionar  sesiones,  usuarios  y altas  o 
inscripciones  de  los  mismos. 

Cookies 

Los  desarrolladores  de  navegadores  hace  tiempo  que  se  dieron  cuenta  de  que  esta 
carencia  de  estados  iba  a representar  un  problema  para  los  desarrolladores  web,  y as! 
fue  como  nacieron  las  cookies  (literalmente  galleta ).  Una  cookie  es  una  pequena 
cantidad  de  information  que  el  servidor  delega  en  el  navegador,  de  forma  que  este  la 
almacena.  Cada  vez  que  el  cliente  web  solicita  una  pagina  del  servidor,  se  le  envia  de 
vuelta  la  cookie. 

Veamos  con  un  poco  mas  de  detalle  el  funcionamiento.  Cuando  abrimos  nuestro 
navegador  y escribimos  google.com,  el  navegador  envia  una  solicitud  HTTP  a Google 
que  empieza  mas  o menos  asi: 

GET  / HTTP/1.1 
Host:  google.com 


Cuando  Google  responde,  la  respuesta  contiene  algo  parecido  a esto: 
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HTTP/1.1  200  OK 
Content -Type : text/html 
Set-Cookie : 

PREF=ID=5bl4f 22bdaf le81c : TM=1167000671 : LM=1167000671 ; 

expires=Sun,  17-Jan-2038  19:14:07  GMT; 
path=/;  domain= . google . com 
Server:  GWS/2.1 


Fijate  en  la  linea  que  comienza  con  Set-Cookie.  El  navegador  almacenara  el  valor 
indicado  (PREF=ID=5bl4f22bdafle81c:TM=1167000671:LM=1167000671)  y se  lo 
volvera  a enviar  a Google  cada  vez  que  vuelva  a acceder  a alguna  de  sus  paginas;  de 
esa  forma,  la  proxima  vez  que  vuelvas  a Google,  la  peticion  que  enviara  el  navegador 
se  parecera  a esta: 

GET  / HTTP/1.1 
Host:  google.com 

Cookie : PREF=ID=5bl4f 22bdaf le81c : TM=1167000671 : LM=1167000671 


Google  puede  saber  ahora,  gracias  al  valor  de  la  Cookie,  que  eres  la  misma  persona 
que  accedio  anteriormente.  Este  valor  puede  ser,  por  ejemplo,  una  clave  en  una  tabla 
de  la  base  de  datos  que  almacene  los  datos  del  usuario.  Con  esa  informacion,  Google 
puede  hacer  aparecer  tu  nombre  en  la  pagina  (de  hecho,  lo  hace). 

Como  definir  y leer  los  valores  de  las  cookies 

A la  hora  de  utilizar  las  capacidades  de  persistencia  de  Django,  lo  mas  probable  es 
que  uses  las  prestaciones  de  alto  nivel  para  la  gestion  de  sesiones  y de  usuarios, 
prestaciones  que  discutiremos  un  poco  mas  adelante  en  este  mismo  capitulo.  No 
obstante,  ahora  vamos  a hacer  una  breve  parada  y veremos  como  leer  y definir 
cookies  a bajo  nivel.  Esto  deberia  ayudarte  a entender  como  funcionan  el  resto  de  las 
herramientas  que  veremos  en  el  capitulo,  y te  sera  de  utilidad  si  alguna  vez  tienes  que 
trabajar  con  las  cookies  directamente. 

Obtener  los  valores  de  las  cookies  que  ya  estan  delinidas  es  muy  facil.  Cada  objeto 
de  tipo  peticion,  request,  contiene  un  objeto  COOKIES  que  se  comporta  como  un 
diccionario;  puedes  usarlo  para  leer  cualquier  cookie  que  el  navegador  haya  enviado 
a la  vista: 

def  mostrar_color(request): 

if  "color_favorito"  in  request.COOKIES: 

return  FlttpResponse("Tu  color  favorito  es  %s"  % \ 
request. COOKIES['color_favorito"]) 

else: 

return  FlttpResponse("No  tienes  un  color  favorito.") 

Definir  los  valores  de  las  cookies  es  solo  un  poco  mas  complicado.  Debes  usar  el 
metodo  set_cookie()  en  un  objeto  de  tipo  HttpResponse.  He  aqui  un  ejemplo  que 
define  la  cookie  color_favorito  utilizando  el  valor  que  se  le  pasa  como  parametro 
GET: 

def  set_color(request): 

if  "color_favorito"  in  request.GET: 

# Crea  un  objeto  FlttpResponse... 
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response  = HttpResponse('Tu  color  favorito  es  ahora  %s"  % \ 
request. GET[  'color_favorito"]) 

# ...  y definimos  la  cookie  en  la  respuesta 

response. set_cookie('color_favorito",  request.  GET['color_favorito"]) 
return  response 
else: 

return  HttpResponse("No  haz  elegido  un  color  favorito.") 


Hay  una  serie  de  parametros  opcionales  que  puedes  pasar  a response. set_cookie()  y 
que  te  permiten  controlar  determinadas  caracteristicas  de  la  cookie,  tal  y como  se 
muestra  en  la  tabla  14- 1 . 


Parametro 

Default 

Descripcion 

max_age 

None 

El  tiempo  (en  segundos)  que  la  cookie  debe  permanecer 
activa.  Si  este  parametro  es  la  cookie,  desaparecera 
automaticamente  cuando  se  cierre  el  navegador. 

expires 

None 

La  fecha  y hora  en  que  la  cookie  debe  expirar.  Debe  estar  en  el 
formato  "Wdy,  DD-Mth-YY  HH:MM:SS  GMT".  Si  se  utiliza  este 
parametro,  su  valor  tiene  preferencia  sobre  el  definido 
mediante  max_age. 

path 

!1  j tt 

La  ruta  o path  para  la  cual  es  valida  la  cookie.  Los  navegadores 
solo  reenviaran  la  cookie  a las  paginas  que  esten  en  dicha  ruta. 
Esto  impide  que  se  envie  esta  cookie  a otras  secciones  de  la 
web. 

Es  especialmente  util  si  no  se  tiene  el  control  del  nivel  superior 
de  directorios  del  servidor  web. 

domain 

None 

El  dominio  para  el  cual  es  valida  la  cookie.  Se  puede  usar  este 
parametro  para  definir  una  cookie  que  sea  apta  para  varios 
dominios.  Por  ejemplo,  definiendo  domain=". example. com" 
la  cookie  sera  enviada  a los  dominios  www.example.com, 
www2.example.com  y aun.otro.subdominio.example.com. 

Si  a este  parametro  no  se  le  asigna  ningun  valor,  la  cookie  solo 
sera  enviada  al  dominio  que  la  delinio. 

secure 

False 

Si  este  valor  se  define  como  True,  se  le  indica  al  navegador  que 
solo  retorne  esta  cookie  a las  paginas  que  se  accedan  de  forma 
segura  (protocolo  HTTPS  en  vez  de  HTTP). 

Table  14-1.  Opciones  de  las  Cookies 


Las  cookies  tienen  doble  filo 


Puede  que  te  hayas  dado  cuenta  de  algunos  de  los  problemas  potenciales  que  se 
presentan  con  esto  de  las  cookies;  vamos  a ver  algunos  de  los  mas  importantes: 

• El  almacenamiento  de  los  cookies  es  voluntario;  los  navegadores  no  dan 
ninguna  garantia.  De  hecho,  los  navegadores  permiten  al  usuario  definir 
una  politica  de  aceptacion  o rechazo  de  las  mismas.  Para  darte  cuenta  de  lo 
muy  usadas  que  son  las  cookies  en  la  web  actual,  simplemente  activa  la 
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option  de  “Avisar  antes  de  aceptar  cualquier  cookie”  y date  un  paseo  por 
Internet. 

A pesar  de  su  uso  habitual,  las  cookies  son  el  ejemplo  perfecto  de  algo  que 
no  es  confiable.  Esto  significa  que  el  desarrollador  debe  comprobar  que  el 
usuario  esta  dispuesto  a aceptar  las  cookies  antes  de  conflar  en  ellas. 

Aun  mas  importante,  nunca  debes  almacenar  informacion  fundamental  en 
las  cookies.  La  Web  rebosa  de  historias  de  terror  acerca  de  desarrolladores 
que  guardaron  informacion  irrecuperable  en  las  cookies  del  usuario,  solo 
para  encontrarse  con  que  el  navegador  habia  borrado  todos  esos  datos  por 
cualquier  razon. 

• Las  Cookies  (especialmente  aquellas  que  no  se  envian  mediante  HTTPS)  no 
son  seguras.  Dado  que  los  datos  enviados  viajan  en  texto  claro,  estan 
expuestas  a que  terceras  personas  lean  esa  informacion,  lo  que  se  llama 
ataques  de  tipo  snooping  (por  snoop,  fisgonear,  husmear).  Por  lo  tanto,  un 
atacante  que  tenga  acceso  al  medio  puede  interceptar  la  cookie  y leer  su 
valor.  El  resultado  de  esto  es  que  nunca  se  debe  almacenar  informacion 
confidencial  en  una  cookie. 

Hay  otro  tipo  de  ataque,  aun  mas  insidioso,  conocido  como  ataque  man- 
in-the-middle  o MitM  (ataque  de  tipo  Hombre-en-medio  o Intermediario) . 
Aqui,  el  atacante  no  solo  intercepta  la  cookie,  sino  que  ademas  la  usa  para 
actuar  ante  el  servidor  como  si  fuera  el  usuario  legitimo.  El  capitulo  19 
describe  en  profundidad  este  tipo  de  ataques,  asi  como  formas  de 
prevenirlo. 

• Las  Cookies  ni  siquiera  son  seguras  para  los  servidores.  La  mayoria  de  los 
navegadores  permiten  manipular  y editar  de  forma  sencilla  los  contenidos 
de  cookies  individuales,  y existen  herramientas  como  mechanize 

(®  http://wwwsearch.sourceforge.net/mechanize/)  que  permiten  a 
cualquiera  que  este  lo  suficientemente  motivado  construir  solicitudes 
HTTP  a mano. 

Asi  que  tampoco  debemos  almacenar  en  las  cookies  datos  que  sean  faciles 
de  falsificar.  El  error  habitual  en  este  escenario  consiste  en  almacenar  algo 
asi  como  IsLoggedIn=l  en  una  cookie  cuando  el  usuario  se  ha  validado.  Te 
sorprenderia  saber  cuantos  sitios  web  cometen  este  tipo  de  error;  no  lleva 
mas  de  unos  segundos  enganar  a sus  sistemas  de  “seguridad”. 


El  entorno  de  sesiones  de  Django 

Con  todas  estas  limitaciones  y agujeros  potenciales  de  seguridad,  es  obvio  que  la 
gestion  de  las  cookies  y de  las  sesiones  persistentes  es  el  origen  de  muchos  dolores  de 
cabeza  para  los  desarrolladores  web.  Por  supuesto,  uno  de  los  objetivos  de  Django  es 
evitar  eflcazmente  estos  dolores  de  cabeza,  asi  que  dispone  de  un  entorno  de 
sesiones  disenado  para  suavizar  y facilitar  todas  estas  cuestiones. 

El  entorno  de  sesiones  te  permite  almacenar  y recuperar  cualquier  dato  que 
quieras  basandote  en  la  sesion  del  usuario.  Almacena  la  informacion  relevante  solo 
en  el  servidor  y abstrae  todo  el  problema  del  envio  y reception  de  las  cookies.  Estas 
solo  almacenan  una  version  codificada  {hash)  del  identificador  de  la  sesion,  y ningun 
otro  dato,  lo  cual  te  aisla  de  la  mayoria  de  los  problemas  asociados  con  las  cookies. 
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Veamos  como  activar  las  sesiones,  y como  usarlas  en  nuestras  vistas. 


Como  activar  las  sesiones 


Las  sesiones  se  implementan  mediante  un  poco  de  middleware  y un  modelo  Django. 
Para  activar  las  sesiones,  necesitas  seguir  los  siguientes  pasos: 

1.  Editar  el  valor  de  MIDDLEWARE_CLASSES  de  forma  que  contenga 
'django. contrib. sessions. middleware. SessionMiddleware'. 

2.  Comprueba  que  'django. contrib. sessions'  este  incluido  en  el  valor  de 
INSTALLED_APPS  (y  ejecuta  el  comando  python  manage. py  migrate) 

El  archivo  por  defecto  settings.py  creado  por  el  comando  startproject  activa  estas 
dos  caracteristicas,  asi  que  a menos  que  las  hayas  borrado,  es  muy  probable  que  no 
tengas  que  hacer  nada  para  empezar  a usar  las  sesiones. 

Si  lo  que  quieres  en  realidad  es  no  usar  sesiones,  deberias  quitar  la  referencia  a 
SessionMiddleware  de  MIDDLEWARE_CLASSES  y borra  'django. contrib. sessions'  de 
INSTALLED_APPS.  Esto  te  ahorrara  solo  un  poco  de  sobrecarga,  pero  toda  ayuda  es 
buena. 


Usando  las  sesiones  en  las  vistas 

Cuando  estan  activadas  las  sesiones,  los  objetos  ElttpRequest  -el  primer  argumento 
de  cualquier  funcion  que  actue  como  una  vista  en  Django  tendran  un  atributo 
llamado  session,  que  se  comporta  igual  que  un  diccionario.  Se  puede  leer  y escribir 
en  el  de  la  misma  forma  en  que  lo  harias  con  un  diccionario  normal.  Por  ejemplo, 
podrias  usar  algo  como  esto  en  una  de  tus  vistas: 

# Asigna  un  valor  a la  sesion: 

request.  session["fav_color"]  = "blue" 

# Trae  el  valor  de  la  sesion  - puede  ser  llamado  en  diferentes  vistas  o e muchas 

# peticiones  t(o  en  ambas): 

fav_color  = request. session["fav_color"j 

# Limpia  el  item  para  la  sesion: 

del  request. session["fav_color"] 

# Verifica  que  la  sesion  contenga  una  clave: 

if  "fav_color"  in  request.session: 


Tambien  puedes  usar  otros  metodos  propios  de  un  diccionario  como  keys()  o 
items ()  en  request.session. 

Elay  dos  o tres  reglas  muy  sencillas  para  usar  eficazmente  las  sesiones  en  Django: 

■ Debes  usar  solo  cadenas  de  texto  normales  como  valores  de  clave  en 
request.session,  en  vez  de,  por  ejemplo,  enteros,  objetos,  etc.  Esto  es  mas 
un  convenio  que  un  regia  en  el  sentido  estricto,  pero  merece  la  pena 
seguirla. 
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■ Los  valores  de  las  claves  de  una  sesion  que  empiecen  con  el  caracter 
subrayado  estan  reservados  para  uso  interno  de  Django.  En  la  practica,  solo 
hay  unas  pocas  variables  asi,  pero,  a no  ser  que  sepas  lo  que  estas  haciendo 
(y  estes  dispuesto  a mantenerte  al  dia  en  los  cambios  internos  de  Django), 
lo  mejor  que  puedes  hacer  es  evitar  usar  el  caracter  subrayado  como  prefijo 
en  tus  propias  variables;  eso  impedira  que  Django  pueda  interferir  con  tu 
aplicacion. 

■ Nunca  reemplaces  request.session  por  otro  objeto,  y nunca  accedas  o 
modifiques  sus  atributos.  Utilizalo  solo  como  si  fuera  un  diccionario. 

Veamos  un  ejemplo  rapido.  Esta  vista  simplificada  define  una  variable 
"ya_comento"  como  True  despues  de  que  el  usuario  haya  publicado  un  comentario. 
Es  una  forma  sencilla  (aunque  no  particularmente  segura)  de  impedir  que  el  usuario 
publique  dos  veces  el  mismo  comentario: 

def  postear_comentario(request): 
if  request. method  !=  ’POST’: 

raise  Http404(’Unicamente  se  permiten  subir  POSTs’) 

if  ’comentario’  not  in  request. POST: 
raise  Http404(’Comentario  no  enviado’) 

if  request. session. get(’ya_comento’,  ): 
return  HttpResponse("Ya  haz  comentado”) 

c = comments. Comment(comment=request.POST[’comment’]) 
c.save() 

request. session[’  ya_comento’]  = 

return  HttpResponse(’iGracias  por  comentar!’) 

Esta  vista  simplificada  permite  que  un  usuario  se  identifique  como  tal  en  nuestras 
paginas: 

def  login(request): 

if  request. method  !=  ’POST’: 

raise  Http404(’Unicamente  se  permiten  metodos  POSTs’) 
try: 

m = Member,  objects.  get(username=request.POST[’username’]) 
if  m. password  ==  request. POST[’password’]: 
request. session[’memberJd’]  = m.id 
return  HttpResponseRedirect(’/you-are-logged-in/’) 
except  Member. DoesNotExist: 

return  HttpResponse(”Tu  nombre  de  usuario  y contrasena  no  coinciden.”) 


Y esta  le  permite  cerrar  o salir  de  la  sesion: 

def  logout(request): 
try: 

del  request. session[’member_id’] 
except  KeyError: 
pass 

return  HttpResponse("Haz  salido  de  la  sesion") 
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Nota:  En  la  practica,  esta  seria  una  forma  pesima  de  validar  a tus  usuarios.  El 
mecanismo  de  autentificacion  que  presentaremos  un  poco  mas  adelante  realiza  esta 
tarea  de  forma  mucho  mas  segura  y robusta.  Los  ejemplos  son  deliberadamente 
simples  para  que  se  comprendan  con  mas  facilidad. 


Comprobar  las  configuraciones  de  las  cookies 

Como  ya  mencionamos,  no  se  puede  confiar  en  que  cualquier  navegador  sea  capaz 
de  aceptar  cookies.  Por  ello,  Django  incluye  una  forma  facil  de  comprobar  que  el 
cliente  del  usuario  disponga  de  esta  capacidad.  Solo  es  necesario  llamar  a la  funcion 
request.session.set_test_cookie()  en  una  vista,  y comprobar  posteriormente,  en  otra 
vista  distinta,  el  resultado  de  llamar  a request.session.test_cookie_worked(). 

Esta  division  un  tanto  extrana  entre  las  llamadas  a set_test_cookie()  y 
test_cookie_worked()  se  debe  a la  forma  es  que  trabajan  las  cookies.  Cuando  se  define 
una  cookie,  no  tienes  forma  de  saber  si  el  navegador  la  ha  aceptado  realmente  hasta 
la  siguiente  solicitud. 

Es  una  practica  recomendable  llamar  a la  funcion  delete_test_cookie()  para  limpiar 
la  cookie  de  prueba  despues  de  haberla  usado.  Lo  mejor  es  hacerlo  justo  despues  de 
haber  verificado  que  las  cookies  funcionan. 

Ele  aqui  un  ejemplo  tipico  de  uso: 

def  login(request): 

# Si  la  peticion  es  POST... 

if  request. method  ==  ’POST’: 

# Prueba  que  la  cookie  trabaje  (ver  abajo): 

if  request.session.test_cookie_worked(): 

# Si  la  cookie  trabaja,  se  borra. 
request. session. delete_test_cookie() 

# En  la  practica  necesitas  alguna  logica  para  verificar  el  nombre  de 

# usuario/contrasena... 

return  HttpResponse("Tu  estas  autentificado.") 

# Si  la  prueba  falla,  se  muestra  un  mensaje  de  error.  En  un  sitio  real  deberias 

# mostrar  un  mensaje  amigable. 
else: 

return  HttpResponse(”Por  favor  habilita  las  cookies  otra  vez. ') 

# Si  no  es  POST,  envia  la  cookie  con  el  formulario  de  autentificacion 

request. session. set_test_cookie() 
return  render(request,  ’foo/login_form.html’) 


Nota:  De  nuevo,  las  funciones  de  autentificacion  ya  definidas  en  el  entorno  se 
encargan  de  realizar  estos  chequeos  por  ti. 


Usar  sesiones  fuera  de  las  vistas 

Internamente,  cada  sesion  es  simplemente  un  modelo  de  entidad  de  Django  como 
cualquier  otro,  definido  en  django.contrib. sessions. models.  Cada  sesion  se  identifica 
gracias  a un  hash  pseudo-alealorio  de  32  caracteres,  que  es  el  valor  que  se  almacena 
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en  la  cookie.  Dado  que  es  un  modelo  normal,  puedes  acceder  a las  propiedades  de  las 
sesiones  usando  la  API  de  acceso  a la  base  de  datos  de  Django: 

»>  from  django.contrib. sessions. models  import  Session 

»>  s = Session. objects. get(pk=’2bll89al88b44adl8c35ell3ac6ceead’) 

»>  s.expire_date 

datetime. datetime(2005,  8,  20, 13,  35, 14) 

Para  poder  acceder  a los  datos  de  la  sesion,  hay  que  usar  el  metodo  get_decoded(). 
Esto  se  debe  a que  estos  datos,  que  consistian  en  un  diccionario,  estan  almacenados 
codificados: 

»>  s.session_data 

’KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...’ 

»>  s.get_decoded() 

{’user_id’:  42} 


Cuando  se  guardan  las  sesiones 


Django,  en  principio,  solo  almacena  la  sesion  en  la  base  de  datos  si  esta  ha  sido 
modificada;  es  decir,  si  cualquiera  de  los  valores  almacenados  en  el  diccionario  es 
asignado  o borrado.  Esto  puede  dar  lugar  a algunos  errores  sutiles,  como  se  indica  en 
el  ultimo  ejemplo: 

# La  sesion  ha  sido  modificada. 

request. session[’foo’]  = ’bar’ 

# La  sesion  ha  sido  modificada. 

del  request. session[’foo’] 

# La  sesion  ha  sido  modificada. 

request. session[’foo’]  = {} 

# La  sesion  NO  ha  sido  modificada,  porque  se  altero 

# request.session[’foo’]  en  lugar  de  request.session. 
request. session[’foo’][’bar’]  = ’baz’ 

Se  puede  cambiar  este  comportamiento,  especificando  la  option 
SESSION_SAVE_EVERY_REQUEST  a True.  Si  lo  hacemos  asi,  Django  almacenara  la 
sesion  en  la  base  de  datos  en  cada  petition,  incluso  si  no  se  ha  modificado  ninguno 
de  sus  valores. 

Fijate  que  la  cookie  de  sesion  solo  se  envia  cuando  se  ha  creado  o modificado  una 
sesion.  Si  SESSION_SAVE_EVERY_REQUEST  esta  como  True,  la  cookie  de  sesion  sera 
reenviada  en  cada  petition.  De  forma  similar,  la  section  de  expiration  (‘’expires’1)  se 
actualizara  cada  vez  que  se  reenvfe  la  cookie. 

Sesiones  breves  frente  a sesiones  persistentes 


Es  posible  que  te  hayas  fijado  en  que  la  cookie  que  nos  envio  Google  al  principio  del 
capitulo  contenia  el  siguiente  texto  expires=Sun,  17-Jan-2038  19:14:07  GMT;.  Las 
Cookies  pueden  incluir  opcionalmente  una  fecha  de  expiration,  que  informa  al 
navegador  el  momento  en  que  se  debe  desechar  por  invalida.  Si  la  cookie  no  contiene 
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ningun  valor  de  expiration,  el  navegador  entiende  que  esta  debe  expirar  en  el 
momento  en  que  se  cierra  el  propio  navegador.  Se  puede  controlar  el 
comportamiento  del  entorno  para  que  use  cookies  de  este  tipo,  breves,  ajustando  en 
valor  de  la  opcion  SESSION_EXPIRE_AT_BROWSER_CLOSE. 

El  valor  por  omision  de  la  opcion  SESSION_EXPIRE_AT_BROWSER_CLOSE  es 
False,  lo  que  significa  que  las  cookies  seran  almacenadas  en  el  navegador  del  usuario 
durante  SESSION_COOKIE_AGE  segundos  (cuyo  valor  por  defecto  es  de  dos 
semanas,  o 1.209.600  segundos).  Estos  valores  son  adecuados  si  no  quieres  obligar  a 
tus  usuarios  a validarse  cada  vez  que  abran  el  navegador  y accedan  a tu  pagina. 

Si  SESSION_EXPIRE_AT_BROWSER_CLOSE  se  establece  a True,  Django  usara 
cookies  que  se  invalidaran  cuando  el  usuario  cierre  el  navegador. 

Otras  caracteristicas  de  las  sesiones 

Ademas  de  las  caracteristicas  ya  mencionadas,  hay  otros  valores  de  configuracion 
que  influyen  en  la  gestion  de  sesiones  con  Django,  tal  y como  se  muestra  en  la  tabla 
14-2. 


1 Opcion 

Description 

Default  j 

SESSION_COOKIE_DOMAIN 

El  Dominio  a utilizar  por  la  cookie  de 
sesion.  Se  puede  utilizar,  por  ejemplo,  el 
valor  ".lawrence.com"  para  utilizar  la 
cookie  en  diferentes  subdominios.  El 
valor  None  indica  una  cookie  estandar. 

None 

SESSION_COOKIE_NAME 

El  nombre  de  la  cookie  de  sesiones. 
Puede  ser  cualquier  cadena  de  texto. 

"sessionid" 

SESSION_COOKIE_SECURE 

Indica  si  se  debe  usar  una  cookie  segura 
para  la  cookie  de  sesion.  Si  el  valor  es 
True,  la  cookie  se  marcara  como  segura, 
lo  que  significa  que  solo  se  podra  utilizar 
mediante  el  protocolo  HTTPS. 

False 

Tabla  14-2.  Valores  de  configuracion  que  influyen  en  el  comportamiento  de  las  cookies 

| DETALLESTECNICOS  | 

Para  los  mas  curiosos,  he  aqui  una  serie  de  notas  tecnicas  acerca  de  algunos  aspectos 
interesantes  de  la  gestion  interna  de  las  sesiones: 


El  diccionario  de  la  sesion  acepta  cualquier  objeto  Python  capaz  de  ser  serializado 
con  pickle.  Vease  la  documentation  del  modulo  pickle  incluido  en  la  biblioteca 
estandar  de  Python  para  mas  information. 

Los  datos  de  la  sesion  se  almacenan  en  una  tabla  en  la  base  de  datos  llamada 
django_session. 

Los  datos  de  la  sesion  son  suministrados  bajo  demanda.  Si  nunca  accedes  al 
atributo  request.session,  Django  nunca  accedera  a la  base  de  datos. 
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Django  solo  envia  la  cookie  si  tiene  que  hacerlo.  Si  no  modilicas  ningun  valor  de  la 
sesion,  no  reenvia  la  cookie  (a  no  ser  que  hayas  deflnido 
SESSION_SAVE_EVERY_REQUEST  como  True). 

El  entorno  de  sesiones  de  Django  se  basa  entera  y exclusivamente  en  las  cookies. 
No  almacena  la  informacion  de  la  sesion  en  las  URL,  como  recurso  extremo  en  el 
caso  de  que  no  se  puedan  utilizar  las  cookies,  como  hacen  otros  entornos  (PE1P,  JSP). 

Esta  es  una  decision  tomada  de  forma  consciente.  Poner  los  identificadores  de 
sesion  en  las  URL  no  solo  hace  que  las  direcciones  sean  mas  feas,  tambien  hace  que 
el  sistema  sea  vulnerable  ante  un  tipo  de  ataque  en  que  se  roba  el  identificador  de  la 
sesion  utilizando  la  cabecera  Referer. 

Si  aun  te  pica  la  curiosidad,  el  codigo  fuente  es  bastante  directo  y claro,  mira  en 
django.contrib. sessions  para  mas  detalles. 


Usuarios  e identificacion 

Estamos  ya  a medio  camino  de  poder  conectar  los  navegadores  con  la  Gente  de 
Verdad™.  Las  sesiones  nos  permiten  almacenar  informacion  a lo  largo  de  las 
diferentes  peticiones  del  navegador;  la  segunda  parte  de  la  ecuacion  es  utilizar  esas 
sesiones  para  validar  al  usuario,  es  decir,  permitirle  hacer  login.  Por  supuesto,  no 
podemos  simplemente  conflar  en  que  los  usuarios  sean  quien  dice  ser,  necesitamos 
autentificarlos  de  alguna  manera. 

Naturalmente,  Django  nos  proporciona  las  herramientas  necesarias  para  tratar 
con  este  problema  tan  habitual  (y  con  muchos  otros).  El  sistema  de  autentificacion  de 
usuarios  de  Django  maneja  cuentas  de  usuarios,  grupos,  permisos  y sesiones  basadas 
en  cookies.  El  sistema  tambien  es  llamado  sistema  aut/aut  (autenticaficacion  y 
autorizacion).  El  no  mb  re  implica  que,  a menudo,  tratar  con  los  usuarios  implica  dos 
procesos.  Se  necesita: 

• Veriflcar  ( autentificacion ) que  un  usuario  es  quien  dice  ser  (Normalmente 
comprobando  un  nombre  de  usuario  y una  contrasena  contra  una  tabla  de 
una  base  de  datos) 

• Veriflcar  que  el  usuario  esta  autorizado  ( autorizacion ) a realizar  una 
operation  determinada  (normalmente  comprobando  una  tabla  de  permisos) 

Siguiendo  estos  requerimientos,  el  sistema  aut/aut  de  Django  consta  de  los 
siguientes  componentes: 

1.  Usuarios:  Personas  registradas  en  tu  sitio  web 

2.  Permisos:  Valores  binarios  (Si/No)  que  indican  si  un  usuario  puede  o no 
realizar  una  tarea  determinada. 

3.  grupos:  Una  forma  generica  de  aplicar  etiquetas  y permisos  a mas  de  un 
usuario. 

4.  mensajes:  Un  mecanismo  sencillo  que  permite  enviar  y mostrar  mensajes  del 
sistema  usando  una  cola. 
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5.  Perfiles:  Un  mecanismo  que  permite  extender  los  objetos  de  tipo  usuario  con 
campos  adicionales. 

Si  ya  has  utilizado  la  herramienta  de  administration  (descrita  en  el  capitulo  6), 
habras  visto  muchas  de  estas  utilidades,  y si  has  modificado  usuarios  y grupos  con 
dicha  herramienta,  ya  has  modificado  las  tablas  en  las  que  se  basa  el  sistema  aut/aut. 


Habilitar  el  soporte  para  autentificacion 

A1  igual  que  ocurria  con  las  sesiones,  el  sistema  de  autentificacion  viene  incluido 
como  una  aplicacion  en  el  modulo  django.contrib,  y necesita  ser  instalado.  De  igual 
manera,  viene  instalado  por  defecto,  por  lo  que  solo  es  necesario  seguir  los  siguientes 
pasos  si  previamente  la  has  desinstalado: 

• Comprueba  que  el  sistema  de  sesiones  este  activo,  tal  y como  se  explico 
previamente  en  este  capitulo.  Seguir  la  pista  de  los  usuarios  implica  usar 
cookies,  y por  lo  tanto  necesitamos  el  entorno  de  sesiones  operativo. 

• Incluye  ' django.contrib. auth'  dentro  de  tu  INSTALLED_APPS  y ejecuta  los 
comandos  makemigration  y migrate. 

• Asegurate  de  que 

'django.contrib. auth.middleware.AuthenticationMiddleware'  esta  incluido  en 
MIDDLEWARE_CLASSES  despues  de  SessionMiddleware. 

Una  vez  resuelto  este  tema,  ya  estamos  preparados  para  empezar  a lidiar  con  los 
usuarios  en  nuestras  vistas.  La  principal  interfaz  que  usaras  para  trabajar  con  los 
datos  del  usuario  dentro  de  una  vista  es  request. user;  es  un  objeto  que  representa  al 
usuario  que  esta  conectado  en  ese  momento.  Si  no  hay  ningun  usuario  conectado, 
este  objeto  sera  una  instancia  de  la  clase  AnonymousUser  (veremos  mas  sobre  esta 
clase  un  poco  mas  adelante). 

Puedes  saber  facilmente  si  el  usuario  esta  identificado  o no  con  el  metodo 
is_authenticated(): 

if  request. user. is_authenticated(): 

# Hacer  algo  con  usuarios  autentificados. 
else: 

# Hacer  algo  con  usuarios  autentificados. 


Utilizando  usuarios 

Una  vez  que  ya  tienes  un  usuario  (normalmente  mediante  request.user,  aunque 
tambien  puede  ser  por  otros  metodos,  que  se  describiran  en  breve)  dispondras  de 
una  serie  de  campos  de  datos  y metodos  asociados  al  mismo.  Los  objetos  de  la  clase 
AnonymousUser  emulan  parte  de  esta  interfaz,  pero  no  toda,  por  lo  que  es  preferible 
comprobar  el  resultado  de  user. is_au the nticatedO  antes  de  asumir  de  buena  fe  que 
nos  encontramos  ante  un  usuario  legitimo.  Las  tablas  14-3  y 14-4  listan  todos  los 
campos  y metodos,  respectivamente,  de  los  objetos  de  la  clase  User. 


Campos  de  los  objetos  User 
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Campo 

Descripcion 

username 

Obligatorio;  30  caracteres  como  maximo.  Solo  acepta  caracteres 
alfanumericos  (letras,  digitos  y el  caracter  subrayado). 

first_name 

Opcional;  30  caracteres  como  maximo. 

last_name 

Opcional;  30  caracteres  como  maximo. 

email 

Opcional.  Direction  de  correo  electronico. 

password 

Obligatorio.  Un  codigo  de  comprobacion  [hash),  junto  con  otros 
metadatos  de  la  contrasena.  Django  nunca  almacena  la  contrasena  en 
crudo.  Vease  la  section  “Cambia  contrasenas”  para  mas  information 

is_staff 

Booleano.  Indica  que  el  usuario  puede  acceder  a las  secciones  de 
administration. 

is_active 

Booleano.  Indica  que  la  cuenta  puede  ser  usada  para  identificarse.  Se 
puede  poner  a False  para  deshabilitar  a un  usuario  sin  tener  que 
borrarlo  de  la  tabla. 

is_superuser 

Booleano.  Senala  que  el  usuario  tiene  todos  los  permisos,  aun  cuando 
no  se  le  hayan  asignado  explicitamente 

lastjogin 

Fecha  y hora  de  la  ultima  vez  que  el  usuario  se  identified.  Se  asigna 
automaticamente  a la  fecha  actual  por  defecto. 

datejoined 

Fecha  y hora  en  que  fue  creada  esta  cuenta  de  usuario.  Se  asigna 
automaticamente  a la  fecha  actual  en  su  momento. 

Tabla  14-3  Campos  de  los  objetos  User 

Metodos  de  los  objetos  User 

Metodo  Descripcion 

is_authenticated  () 


is_anonymous() 


get_full_name() 

set_password(passwd) 


check_password(passwd) 


Siempre  devuelve  True  para  usuario  reales.  Es  una 
forma  de  determinar  si  el  usuario  se  ha  identiflcado. 
esto  no  implica  que  posea  ningun  permiso,  y 
tampoco  comprueba  que  la  cuenta  este  activa.  Solo 
indica  que  el  usuario  se  ha  identificado  con  exito. 
Devuelve  True  solo  para  usuarios  anonimos,  y False 
para  usuarios  “reales”.  En  general,  es  preferible  usar 
el  metodo  is_authenticated(). 

Devuelve  la  concatenation  de  los  campos 
first_name  y last_name,  con  un  espacio  en  medio. 
Cambia  la  contrasena  del  usuario  a la  cadena  de 
texto  en  claro  indicada,  realizando  internamente  las 
operaciones  necesarias  para  calcular  el  codigo  de 
comprobacion  o hash  necesario.  Este  metodo  no 
guarda  el  objeto  User. 

devuelve  True  si  la  cadena  de  texto  en  claro  que  se 
le  pasa  coincide  con  la  contrasena  del  usuario. 
Realiza  internamente  las  operaciones  necesarias 
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get_group_permissions  () 
get_all_permissions  () 
has_perm(perm) 

has_perms  (permjist) 
has_module_perms  (appjahel) 
get_and_delete_messages  () 
email_user(subj,  msg) 


para  calcular  los  codigos  de  comprobacion  o hash 
necesarios. 

Devuelve  una  lista  con  los  permisos  que  tiene  un 
usuario,  obtenidos  a traves  del  grupo  o grupos  a las 
que  pertenezca. 

Devuelve  una  lista  con  los  permisos  que  tiene 
concedidos  un  usuario,  ya  sea  a traves  de  los  grupos 
a los  que  pertenece  o bien  asignados  directamente. 
Devuelve  True  si  el  usuario  tiene  el  permiso 
indicado.  El  valor  de  perm  esta  en  el  formato 
'"package. codename".  Si  el  usuario  no  esta  activo, 
siempre  devolvera  False. 

Devuelve  True  si  el  usuario  tiene  todos  los  permisos 
indicados.  Si  el  usuario  no  esta  activo,  siempre 
devolvera  False. 

Devuelve  True  si  el  usuario  tiene  algun  permiso  en 
la  etiqueta  de  aplicacion  indicada,  appjahel.  Si  el 
usuario  no  esta  activo,  siempre  devolvera  False. 
Devuelve  una  lista  de  mensajes  (objetos  de  la  clase 
Message)  de  la  cola  del  usuario,  y los  borra 
posteriormente. 

Envia  un  correo  electronico  al  usuario.  El  mensaje 
aparece  como  enviado  desde  la  direction  indicada 
en  el  valor  DEFAULT_FROM_EMAIE.  Se  le  puede 
pasar  un  tercer  parametro  opcional,  from_email, 
para  indicar  otra  direction  de  remite  distinta. 


Tabla  14-4.  Metodos  de  los  objetos  User 


Por  ultimo,  los  objetos  de  tipo  User  mantienen  dos  campos  de  relaciones 
multiples  o muchos-a-muchos:  Grupos  y permisos  (groups  y permissions).  Se  puede 
acceder  a estos  objetos  relacionados  de  la  misma  manera  en  que  se  usan  otros 
campos  multiples: 

# Asignar  un  usuario  a un  grupo: 

»>myuser.groups  = groupjist 

# Agregar  un  usuario  a un  grupo: 

»>myuser.groups.add(groupl,  group2,...) 

# Quitar  un  usuario  de  algun  grupo: 

»>myuser.groups.remove(groupl,  group2,...) 

#Quitar  un  usuario  de  todos  los  grupos: 

»>myuser.groups.clear() 

#Los  permisos  trabajan  de  la  misma  forma 

»>myuser.permissions  = [permissionjist] 

»>myuser.permissions.add(permissionl,  permission2,  ...) 
»>myuser.permissions.remove(permissionl,  permission2,  ...) 
»>myuser.permissions.clear() 
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Iniciar  y cerrar  sesion 

Django  proporciona  vistas  predeflnidas  para  gestionar  la  entrada  del  usuario,  (el 
momento  en  que  se  identifica),  y la  salida,  (es  decir,  cuando  cierra  la  sesion),  ademas 
de  otros  trucos  ingeniosos.  Pero  antes  de  entrar  en  detalles,  veremos  como  hacer  que 
el  usuario  puedan  iniciar  y cerrar  la  sesion  “a  mano”.  Django  incluye  dos  funciones 
para  realizar  estas  acciones,  en  el  modulo  django.contrib.auth:  authenticate!)  y 
login(). 

Para  autentificar  un  identificador  de  usuario  y una  contrasena,  se  utiliza  la  funcion 
authenticate!),  esta  funcion  acepta  dos  parametros  , username  y password,  y 
devuelve  un  objeto  de  tipo  User  si  la  contrasena  es  correcta  para  el  identificador  de 
usuario.  Si  falla  la  comprobacion  (ya  sea  porque  sea  incorrecta  la  contrasena  o 
porque  sea  incorrecta  la  identification  del  usuario),  la  funcion  devolvera  None: 

»>  from  django.contrib  import  auth 

»>  user  = auth.authenticate(username- john’,  password- secret’) 

»>  if  user  is  not  one: 
print  ("iCorrecto!") 
else: 

print  ("iOops,  algo  anda  mal!") 

La  llamada  a authenticate!)  solo  veriflca  las  credenciales  del  usuario.  Todavia  hay 
que  realizar  una  llamada  a login!)  para  completar  el  inicio  de  sesion.  La  llamada  a 
login!)  acepta  un  objeto  de  la  clase  HttpRequest  y un  objeto  User  y almacena  el 
identificador  del  usuario  en  la  sesion,  usando  el  entorno  de  sesiones  de  Django. 

El  siguiente  ejemplo  muestra  el  uso  de  ambas  funciones,  authenticate!)  y login!), 
dentro  de  una  vista: 

from  django.contrib  import  auth 

def  vistajogin(request): 

username  = request. POST.get(’username’,  ”) 
password  = request.  POST. get(’password',  ”) 

user  = auth.authenticate(username=username,  password=password) 
if  user  is  not  Nor  and  user.is_active: 

# Contrasena  correcta  y usuario  marcado  como  "activo" 

auth.login(request,  user) 

# Redireccciona  a una  pagina  de  entrada  correcta. 

return  HttpResponseRedirect("/account/loggedin/") 
else: 

# Muestra  una  pagina  de  error 

return  HttpResponseRedirect("/account/invalid/") 

Para  cerrar  la  sesion,  se  puede  llamar  a django.contrib. auth.logoutf)  dentro  de  una 
vista. 

Necesita  que  se  le  pase  como  parametro  un  objeto  de  tipo  HttpRequest,  y no 
devuelve  ningun  valor: 

from  django.contrib  import  auth 

def  logout(request): 
auth.logout(request) 

# Redireccciona  a una  pagina  de  entrada  correcta. 

return  HttpResponseRedirect(7account/loggedout/') 
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La  llamada  a logoutO  no  produce  ningun  error,  aun  si  no  hubiera  ningun  usuario 
conectado. 

En  la  practica,  no  es  normalmente  necesario  escribir  tus  propias  funciones  para 
realizar  estas  tareas;  el  sistema  de  autentificacion  viene  con  un  conjunto  de  vistas 
predefinidas  para  ello.  El  primer  paso  para  utilizar  las  vistas  de  autentificacion  es 
mapearlas  en  tu  URLconf. 

Necesitas  modificar  tu  codigo  hasta  tener  algo  parecido  a esto: 
from  django.contrib.auth. views  import  login,  logout 

urlpatterns  = [ 

# mas  patrones  aqui... 

url(r’Aaccounts/login/$’,  login), 
url(r’Aaccounts/logout/$’,  logout), 

3 


/accounts/login/  y /accounts /logout/  son  las  URL  por  defecto  que  usa  Django 
para  estas  vistas. 

Por  defecto,  la  vista  de  login  utiliza  la  plantilla  definida  en  registration/login.html 
(puedes  cambiar  el  nombre  de  la  plantilla  utilizando  un  parametro  opcional, 
template_name).  El  formulario  necesita  contener  un  campo  llamado  username  y otro 
llamado  password.  Una  plantilla  de  ejemplo  podria  ser  esta: 

{%  extends  "base.html"  %} 

{%  block  content  %} 

{%  if  form. errors  %} 

<p  class="error">Lo  sentimos,  la  contrasena  y el  nombre  de  usuario  no  son 
validos</p> 

{%  endif  %} 

<form  action=""  method="post"> 

<label  for="username">User  name:</label> 

<input  type="text"  name="username"  value=""  id="username"> 

<label  for="password">Password:</label> 

<input  type="password"  name="password"  value-'"  id="password"> 

<input  type="submit"  value="login"  /> 

<input  type="hidden"  name="next"  value="{{  next|escape  }}"  /> 

</form> 

{%  endblock  %} 

Si  el  usuario  se  identifica  correctamente,  su  navegador  sera  redirigido  a 
/accounts/profile/.  Puedes  indicar  una  direction  distinta  especificando  un  tercer 
campo  (normalmente  oculto)  que  se  llame  next,  cuyo  valor  debe  ser  la  URL  a 
redireccionar  despues  de  la  identification.  Tambien  puedes  pasar  este  valor  como  un 
parametro  GET  a la  vista  de  identification  y se  anadira  automaticamente  su  valor  al 
contexto  en  una  variable  llamada  next,  que  puedes  incluir  ahora  en  un  campo  oculto. 

La  vista  de  cierre  de  sesion  se  comporta  de  forma  un  poco  diferente.  Por  defecto 
utiliza  la  plantilla  definida  en  registration/logged_out.html  (que  normalmente 
contiene  un  mensaje  del  tipo  “Ha  cerrado  su  sesion”).  No  obstante,  se  puede  llamar  a 
esta  vista  con  un  parametro  extra,  llamado  next_page,  que  indicaria  la  vista  a la  que 
se  debe  redirigir  una  vez  efectuado  el  cierre  de  la  sesion. 
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Limitar  el  acceso  a los  usuarios  identificados 


Por  supuesto,  la  razon  de  haber  implementado  todo  este  sistema  es  permitirnos 
limitar  el  acceso  a determinadas  partes  de  nuestro  sitio. 

La  forma  mas  simple  y directa  de  limitar  este  acceso  es  comprobar  el  resultado  de 

llamar  a la  funcion  request. user. is_authenticated()  y redirigir  a una  pagina  de 

identification,  si  procede: 

from  django. shortcuts  import  redirect 

def  mi_vista(request): 

if  not  request. user. is_authenticated(): 

return  redirect('/login/?next=%s'  % request. path) 

# ... 

O quizas  mostrar  un  mensaje  de  error: 

from  django. shortcuts  import  render 

def  mi_vista(request): 

if  not  request. user. is_authenticated(): 

return  render(request,  'myapp/login_error.htmr) 

# ... 

Si  se  desea  abreviar,  se  puede  usar  el  decorador  login_required  sobre  las  vistas 
que  nos  interese  proteger: 

from  django. contrib.auth. decorators  import  login_required 

@login_required 
def  mi_vista(request): 

# ... 

Esto  es  lo  que  hace  el  decorador:  " login_required" 

• Si  el  usuario  no  esta  identificado,  redirige  a la  direction  /accounts/login/, 
incluyendo  la  url  actual  como  un  parametro  con  el  nombre  next,  por  ejemplo 
/ accounts  /login/  ?next=  /polls  131. 

• Si  el  usuario  esta  identificado,  ejecuta  la  vista  sin  ningun  cambio.  La  vista 
puede  asumir  sin  problemas  que  el  usuario  esta  identificado  correctamente. 


Limitar  el  acceso  a usuarios  que  pasan  una  prueba 

Se  puede  limitar  el  acceso  basandose  en  ciertos  permisos  o en  algun  otro  tipo  de 
prueba,  o proporcionar  una  pagina  de  identiflcacion  distinta  de  la  vista  por  defecto,  y 
las  dos  cosas  se  hacen  de  manera  similar. 

La  forma  mas  cruda  es  ejecutar  las  pruebas  que  queremos  hacer  directamente  en 
el  codigo  de  la  vista.  Por  ejemplo,  para  comprobar  que  el  usuario  esta  identificado  y 
que,  ademas,  tenga  asignado  el  permiso  por  ejemplo:  biblioteca.votar  (se  explicara 
esto  de  los  permisos  con  mas  detalle  dentro  de  poco)  hariamos: 
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def  votar(request): 

if  request. user. is_authenticated()  and  request. user. has_perm('biblioteca.votar')): 

# Votar  aqui: 

else: 

return  HttpResponse("Puedes  votar.") 

De  nuevo,  Django  proporciona  una  forma  abreviada  llamada  user_passes_test(). 
Requiere  que  se  la  pasen  unos  argumentos  y genera  un  decorador  especializado  para 
cada  situation  en  particular: 

def  puede_votar(user): 

return  user.is_authenticated()  and  user.has_perm( 'biblioteca.puede_votar") 

@user_passes_test(puede_votar,  login_url- '/login/") 
def  votar(request): 


El  decorador  user_passes_test  tiene  un  parametro  obligatorio:  un  objeto  que  se 
pueda  llamar  (normalmente  una  funcion)  y que  a su  vez  acepte  como  parametro  un 
objeto  del  tipo  User,  y devuelva  True  si  el  usuario  puede  acceder  y False  en  caso 
contrario.  Es  importante  destacar  que  user_passes_test  no  comprueba 
automaticamente  que  el  usuario  este  identificado;  esa  es  una  comprobacion  que  se 
debe  hacer  explicitamente. 

En  este  ejemplo,  hemos  usado  tambien  un  segundo  parametro  opcional,  login_url, 
que  te  permite  indicar  la  url  de  la  pagina  que  el  usuario  debe  utilizar  para 
identificarse  (/accounts/login/  por  defecto). 

Comprobar  si  un  usuario  posee  un  determinado  permiso  es  una  tarea  muy 
frecuente,  asi  que  Django  proporciona  una  forma  abreviada  para  estos  casos:  El 
decorador  permission_required().  Usando  este  decorador,  el  ejemplo  anterior  se 
podria  codificar  asi: 

from  django.contrib.auth. decorators  import  permission_required 

@permission_required('biblioteca.puede_votar',  login_url- '/login/") 
def  votar(request): 

# ... 

El  decorador  permission_required()  tambien  acepta  el  parametro  opcional 
login_url,  de  nuevo  con  el  valor  /accounts/login/  en  caso  de  omision. 


Limitar  el  acceso  a vistas  genericas 

Una  de  las  preguntas  mas  frecuentes  en  la  lista  de  usuarios  de  Django  trata  de  como 
limitar  el  acceso  a una  vista  generica.  Para  conseguirlo,  tienes  que  usar  un 
recubrimiento  sencillo  alrededor  de  la  vista  que  quieres  proteger  o apuntar  en  tu 
URLconf  al  recubrimiento  en  vez  de  a la  vista  generica. 

Puedes  cambiar  el  decorador  login_required  por  cualquier  otro  que  quieras  usar, 
como  es  logico. 

La  forma  mas  simple  de  limitar  el  acceso  a una  vista  generica  basada  en 
clases,  es  poner  un  decorador  en  la  URLconf,  en  el  metodo  as_view()  asi: 

from  django.contrib.auth. decorators  import  login_required,  permission_required 
from  django. views. generic  import  TemplateView 
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from  .views  import  VoteView 

urlpatterns  = [ 

#... 

url(r'Aabout/',  login_required(TemplateView.as_view( 
template_name="secreto.html"))), 

url(r'Avotar/',  permission_required('biblioteca.puede_votar')(VistaVotar.as_view())), 

] 


Para  limitar  el  acceso  a una  vista  basada  en  una  clase,  solo  decora  el  metodo 
dispatch  ()  asi: 

from  django.contrib.auth. decorators  import  login_required 
from  django. utils. decorators  import  method_decorator 
from  django. views. generic  import  TemplateView 

class  VistaProtegida(TemplateView): 

template_name  = 'secreto.html' 

@method_decorator(login_required) 
def  dispatch(self,  *args,  **kwargs): 

return  super(VistaProtegida,  self).dispatch(*args,  **kwargs) 


Gestionar  usuarios,  permisos  y grupos 

La  forma  mas  facil  de  gestionar  el  sistema  de  autentificacion  es  a traves  de  la  interfaz 
de  administration  admin.  El  capitulo  6 describe  como  usar  esta  interfaz  para 
modificar  los  datos  de  los  usuarios  y controlar  sus  permisos  y accesos,  y la  mayor 
parte  del  tiempo  esa  es  la  forma  mas  adecuada  de  gestion. 

A veces,  no  obstante,  hace  falta  un  mayor  control,  y para  eso  podemos  utilizar  las 
llamadas  a bajo  nivel  que  describiremos  en  este  capitulo. 

Crear  usuarios 

Puedes  crear  usuarios  con  el  metodo  create_user(): 

»>  from  django.contrib.auth. models  import  User 
»>  user  = User. objects. create_user(username='john', 

email-jlennon@beatles.com', 
password- glass  onion') 

»> 

#En  este  punto,  user  es  una  instancia  de  la  clase  User,  preparada  para 

# ser  almacenada  en  la  base  de  datos  (create_user()  no  llama  al  metodo  save()).  Este 

# te  permite  cambiar  algunos  de  sus  atributos  antes  de  guardarlos,  si  quieres: 

»>  user.last_name  = 'Lennon' 

»>  user.is_staff  = True 
»>  user.saveQ 


Puedes  usar  django-admin  para  realizar  este  trabajo  interactivamente 
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Cambia  contrasenas 

Puedes  cambiar  las  contrasena  de  un  usuario  llamando  a set_password(): 

»>  from  django.contrib.auth. models  import  User 
»>  user  = User. objects. get(username='john') 

»>  user.set_password('nueva-contrasena') 

»>  user.save() 

No  debes  modificar  directamente  el  atributo  password,  a no  ser  que  tengas  muy 
claro  lo  que  estas  haciendo.  La  contrasena  se  almacena  en  la  base  de  datos  en  forma 
de  codigo  de  comprobacion  ( salted  hash ) y,  por  tanto,  debe  ser  modificada  solo  a 
traves  de  este  metodo. 

Para  ser  mas  exactos,  el  atributo  password  de  un  objeto  User  es  una  cadena  de 
texto  con  el  siguiente  formato: 

hashtype$salt$hash 

Es  decir,  el  tipo  de  hash,  el  grano  de  sal  {salt)  y el  codigo  hash  propiamente  dicho, 
separados  entre  si  por  el  caracter  dolar  ($). 

El  valor  de  hashtype  puede  ser  shal  (por  defecto)  o md5,  el  algoritmo  usado  para 
realizar  una  transformation  hash  de  un  solo  sentido  sobre  la  contrasena.  El  grano  de 
sal  es  una  cadena  de  texto  aleatoria  que  se  utiliza  para  aumentar  la  resistencia  de  esta 
codification  frente  a un  ataque  por  diccionario.  Por  ejemplo: 

Shal$al976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 

Las  funciones  User.set_password()  y User.check_password()  manejan  todos  estos 
detalles  y comprobaciones  de  forma  transparente. 

^Tengo  que  echar  sal  a mi  ordenador? 

No,  la  sal  de  la  que  hablamos  no  tiene  nada  que  ver  con  ninguna  receta  de  cocina;  es 
una  forma  habitual  de  aumentar  la  seguridad  a la  hora  de  almacenar  una  contrasena. 

Una  funcion  hash  es  una  funcion  criptografica,  que  se  caracteriza  por  ser  de  un 
solo  sentido;  es  decir,  es  facil  calcular  el  codigo  hash  de  un  determinado  valor,  pero 
es  practicamente  imposible  reconstruir  el  valor  original  partiendo  unicamente  del 
codigo  hash. 

Si  almacenaramos  las  contrasenas  como  texto  en  claro,  cualquiera  que  pudiera 
obtener  acceso  a la  base  de  datos  podria  saber  sin  ninguna  dificultad  todas  las 
contrasenas  al  instante.  Al  guardar  las  contrasenas  en  forma  de  codigos  hash  se 
reduce  el  peligro  en  caso  de  que  se  comprometa  la  seguridad  de  la  base  de  datos. 

No  obstante,  un  atacante  que  pudiera  acceder  a la  base  de  datos  podria  ahora 
realizar  un  ataque  por  fuerza  bruta,  calculando  los  codigos  hash  de  millones  de 
contrasenas  distintas  y comparando  esos  codigos  con  los  que  estan  almacenados  en 
la  base  de  datos.  Este  llevara  algo  de  tiempo,  pero  menos  de  lo  que  parece,  los 
ordenadores  son  increiblemente  rapidos. 

Para  empeorar  las  cosas,  hay  disponibles  publicamente  lo  que  se  conoce  como 
tablas  arco  iris  ( rainbow  tables),  que  consisten  en  valores  hash  precalculados  de 
millones  de  contrasenas  de  uso  habitual.  Usando  una  tabla  arco  iris,  un  atacante 
puede  romper  la  mayoria  de  las  contrasenas  en  segundos. 

Para  aumentar  la  seguridad,  se  anade  un  valor  inicial  aleatorio  y diferente  a cada 
contrasena  antes  de  obtener  el  codigo  hash.  Este  valor  aleatorio  es  el  “grano  de  sal”. 

Como  cada  grano  de  sal  es  diferente  para  cada  password  se  evita  el  uso  de  tablas 
arco  iris,  lo  que  obliga  al  atacante  a volver  al  sistema  de  ataque  por  fuerza  bruta,  que 
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a su  vez  es  mas  complicado  al  haber  aumentado  la  entropia  con  el  grano  de  sal.  Otra 
ventaja  es  que  si  dos  usuarios  eligen  la  misma  contrasena,  al  anadir  el  grano  de  sal  los 
codigos  hash  resultantes  seran  diferentes. 

Aunque  esta  tecnica  no  es,  en  terminos  absolutos,  la  mas  segura  posible,  ofrece  un 
buen  compromiso  entre  seguridad  y conveniencia. 

El  alta  de  usuarios 

Podemos  usar  estas  herramientas  de  bajo  nivel  para  crear  vistas  que  permitan  al 
usuario  darse  de  alta.  Practicamente  todos  los  desarrolladores  quieren  implementar 
el  alta  del  usuario  a su  manera,  por  lo  que  Django  te  da  la  option  de  crearte  tu  propia 
vista  para  ello.  Afortunadamente,  es  muy  facil  de  hacer. 

La  forma  mas  sencilla  es  escribir  una  pequena  vista  que  pregunte  al  usuario  los 
datos  que  necesita  y con  ellos  se  cree  directamente  el  usuario.  Django  proporciona 
un  formulario  prefabricado  que  se  puede  usar  con  este  fin,  como  se  muestra  en  el 
siguiente  ejemplo: 


biblioteca/forms .py 


from  django  import  forms 

from  django. contrib.auth. forms  import  UserCreationForm 
from  django. http  import  HttpResponseRedirect 
from  django. shortcuts  import  render 

def  registrar(request): 

if  request. method  ==  'POST': 

form  = UserCreationForm(request.POST) 
if  form.is_valid(): 

new_user  = form.save() 

return  PlttpResponseRedirect(7libros/") 

else: 

form  = UserCreationForm() 
return  render(request,  "biblioteca/registro.htmr,  { 

'form':  form, 

}) 

Este  formulario  asume  que  existe  una  plantilla  llamada  biblioteca/registro.html.  Esta 
plantilla  podrfa  consistir  en  algo  parecido  a esto: 


templates/biblioteca/registro . html 


{%  extends  "base.html"  %} 

{%  block  title  %}Crea  una  cuenta{%  endblock  %} 

{%  block  content  %} 

<hl>  Crea  una  cuenta  de  usuario</hl> 

<form  action=""  method="post">  {%  csrf_token  %} 
{{ form.as_p }} 

<input  type="submit"  value="Crea  una  cuenta"> 
</form> 

{%  endblock  %} 
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Usar  information  de  autentificacion  en  plantillas 

El  usuario  actual,  asi  como  sus  permisos,  estan  disponibles  en  el  contexto  de  la 
plantilla  cuando  usas  RequestContext  (vease  Capitulo  10). 


■Nota:  Tecnicamente  hablando,  estas  variables  estan  disponibles  en  el  contexto  de  la 
plantilla  solo  si  usas  RequestContext  ye n la  configuration  esta  incluido  el  valor 
"django.core.context_processors.auth"  en  la  option 

TEMPLATE_CONTEXT_PROCESSORS,  que  es  el  valor  que  viene  predefinido  cuando 
se  crea  un  proyecto.  Como  ya  se  comento,  vease  el  capitulo  10 para  mas  information. 


Cuando  se  usa  RequestContext,  el  usuario  actual  (ya  sea  una  instancia  de  User  o 
de  AnonymousUser)  es  accesible  en  la  plantilla  con  el  nombre  {{  user }}: 

{%  if  user.is_authenticated  %} 

<p>Bienvenido,  {{  user. username  }}.  Gracias  por  identificarte.</p> 

{%  else  %} 

<p>Bienvenido,  nuevo  usuario.  Por  favor  identiffcate.</p> 

{%  endif  %} 

Los  permisos  del  usuario  se  almacenan  en  la  variable  {{  perms  }}.  En  realidad,  es  una 
forma  simplificada  de  acceder  a un  par  de  metodos  sobre  los  permisos  que  veremos 
en  breve. 

Elay  dos  formas  de  usar  este  objeto  perms.  Puedes  usar  {{  perms.polls  }}  para 
comprobar  si  un  usuario  tienen  algun  permiso  para  una  determinada  aplicacion,  o se 
puede  usar  una  forma  mas  especffica,  como  {{  perms.polls. can_vote  }},  para 
comprobar  si  el  usuario  tiene  concedido  un  permiso  en  concreto. 

Por  lo  tanto,  se  pueden  usar  estas  comprobaciones  en  sentencias  {%  if  %}: 

{%  if  perms. biblioteca  %} 

<p>Tienes  permisos  para  publicar  libros.</p> 

{%  if  perms. biblioteca. puede_votar  %} 

<p>iPuedes  votar  en  las  encuestas!</p> 

{%  endif  %} 

{%  else  %} 

<p>No  tienes  ningun  permiso  en  esta  aplicacion. </p> 

{%  endif  %} 


El  resto  de  detalles:  permisos,  grupos,  mensajes 

Elay  unas  cuantas  cosas  que  pertenecen  al  entorno  de  autentificacion  y que  hasta 
ahora  solo  hemos  podido  ver  de  pasada.  En  esta  section  las  veremos  con  un  poco 
mas  de  detalle. 

Permisos 

Los  permisos  son  una  forma  sencilla  de  “marcar”  que  determinados  usuarios  o 
grupos  pueden  realizar  una  action.  Se  usan  normalmente  para  la  parte  de 
administration  de  Django,  pero  puedes  usarlos  tambien  en  tu  codigo. 

El  sistema  de  administration  de  Django  utiliza  los  siguientes  permisos: 
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■ Acceso  a visualizar  el  formulario  “Anadir”,  y Anadir  objetos,  esta  limitado  a los 
usuarios  que  tengan  el  permiso  add  para  ese  tipo  de  objeto. 

■ El  acceso  a la  lista  de  cambios,  ver  el  formulario  de  cambios  y cambiar  un 
objeto  esta  limitado  a los  usuarios  que  tengan  el  permisos  change  para  ese 
tipo  de  objeto. 

■ Borrar  objetos  esta  limitado  a los  usuarios  que  tengan  el  permiso  delete  para 
ese  tipo  de  objeto. 

Los  permisos  se  definen  a nivel  de  las  clases  o tipos  de  objetos,  no  a nivel  de 
instancias.  Por  ejemplo,  se  puede  decir  “Maria  puede  modificar  los  reportajes 
nuevos”,  pero  no  “Maria  solo  puede  modificar  los  reportajes  nuevos  que  haya  creado 
ella”,  ni  “Maria  solo  puede  cambiar  los  reportajes  que  tengan  un  determinado  estado, 
fecha  de  publication  o identificador”. 

Estos  tres  permisos  basicos,  anadir,  cambiar  y borrar,  se  crean  automaticamente 
para  cualquier  modelo  Django  que  incluya  una  clase  Admin.  Entre  bambalinas,  los 
permisos  se  agregan  a la  tabla  auth_permission  cuando  ejecutas  manage.py  migrate. 
Estos  permisos  se  crean  con  el  siguiente  formato:  "<app>.<action>_<object_name>". 
Por  ejemplo,  si  tienes  una  aplicacion  llamada  encuestas,  con  un  modelo  llamado 
Respuesta,  se  crearan  automaticamente  los  tres  permisos  con  los  nombres 
" encuestas. add_respuesta", " encuestas. change_respuesta"  y 
" encuestas.  delete_respuesta". 

Igual  que  con  los  usuarios,  los  permisos  se  implementa  en  un  modelo  Django  que 
reside  en  el  modulo  django.contrib.auth.models.  Esto  significa  que  puedes  usar  la 
API  de  acceso  a la  base  de  datos  para  interactuar  con  los  permisos  de  la  forma  que 
quieras. 

Grupos 

Los  grupos  son  una  forma  generica  de  trabajar  con  varios  usuarios  a la  vez,  de  forma 
que  se  les  pueda  asignar  permisos  o etiquetas  en  bloque.  Un  usuario  puede 
pertenecer  a varios  grupos  a la  vez. 

Un  usuario  que  pertenezca  a un  grupo  recibe  automaticamente  todos  los  permisos 
que  se  la  hayan  otorgado  al  grupo.  Por  ejemplo,  si  el  grupo  Editores  tiene  el  permiso 
can_edit_home_page,  cualquier  usuario  que  pertenezca  a dicho  grupo  tambien  tiene 
ese  permiso. 

Los  grupos  tambien  son  una  forma  comoda  de  categorizar  a los  usuarios  para 
asignarles  una  determinada  etiqueta,  o para  otorgarles  una  funcionalidad  extra.  Por 
ejemplo,  se  puede  crear  un  grupo  Usuarios  especiales,  y utilizar  codigo  para  permitir 
el  acceso  a determinadas  porciones  de  tu  sitio  solo  a los  miembros  de  ese  grupo,  o 
para  enviarles  un  correo  electronico  solo  a ellos. 

Al  igual  que  con  los  usuarios,  la  manera  mas  sencilla  de  gestionar  los  grupos  es 
usando  la  interfaz  de  administration  de  Django.  Los  grupos,  en  cualquier  caso,  son 
modelos  Django  que  residen  en  el  modulo  django.contrib.auth.models  asi  que,  al 
igual  que  en  el  caso  anterior,  puedes  usar  la  API  de  acceso  a la  base  de  datos  para 
trabajar  con  los  grupos  a bajo  nivel. 

Mensajes 

El  sistema  de  mensajes  es  una  forma  muy  ligera  y sencilla  de  enviarle  mensajes  a un 
usuario.  Cada  usuario  tiene  asociada  una  cola  de  mensajes,  de  forma  que  los 
mensajes  lleguen  en  el  orden  en  que  fueron  enviados.  Los  mensajes  no  tienen  ni 
fecha  de  caducidad  ni  fecha  de  envio. 
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La  interfaz  de  administration  de  Django  usa  los  mensajes  para  notificar  que 
determinadas  acciones  han  podido  ser  llevadas  a cabo  con  exito.  Por  ejemplo,  al 
crear  un  objeto,  veras  que  aparece  un  mensaje  en  lo  alto  de  la  pagina  de 
administration,  indicando  que  se  ha  podido  crear  el  objeto  sin  problemas. 

Puedes  usar  la  misma  API  para  enviar  o mostrar  mensajes  en  tu  propia  aplicacion. 
Las  llamadas  de  la  API  son  bastante  simples: 

Para  crear  un  nuevo  mensaje  usa 

user.message_set.create(message='message_text'). 

Para  recuperar/eliminar  mensajes  usa  user.get_and_delete_messages(),  la  cual 
retorna  una  lista  de  objetos  Message  en  la  cola  del  usuario  (si  es  que  existiera  alguno) 
y elimina  el  mensaje  de  la  misma. 

En  el  siguiente  ejemplo,  la  vista  guarda  un  mensaje  para  el  usuario  despues  de 
crear  una  lista  de  reproduction: 

def  crear_lista(request,  songs): 

# Crea  un  lista  de  reproduccion  con  las  canciones  dadas. 

# ... 

request. user.  message_set.create( 

message="Tu  lista  fue  agregada  correctamente." 

) 

return  render_to_response("playlists/crear.html", 
context_instance=RequestContext(request)) 

Al  usar  RequestContext,  los  mensajes  del  usuario  actual,  si  los  tuviera,  estan 
accesibles  desde  la  variable  de  contexto  usando  el  nombre  {{  messages  }}.  El 
siguiente  ejemplo  representa  un  fragmento  de  codigo  que  muestras  los  mensajes: 

{%  if  messages  %} 

<ul> 

{%  for  message  in  messages  %} 

<li>{{  message  }}</li> 

{%  endfor  %} 

</ul> 

{%  endif  %} 

Hay  que  hacer  notar  que  RequestContext  llama  a get_and_delete_messages  de 
forma  implicita,  por  lo  que  los  mensajes  seran  borrados,  aun  si  no  se  muestran  en 
pantalla. 

Por  ultimo,  el  sistema  de  mensajeria  solo  funciona  para  usuarios  de  la  base  de 
datos.  Para  enviar  mensajes  a usuarios  anonimos  hay  que  usar  en  entorno  de 
sesiones  directamente. 

i,Que  sigue? 

La  verdad  es  que  el  sistema  de  autorizacion  tiene  tela  de  donde  cortar.  Sin  embargo  la 
mayoria  de  las  veces  no  tendras  que  preocuparte  por  todos  los  detalles  que  se 
describen  en  este  capitulo,  pero  si  alguna  vez  tienes  que  gestionar  interacciones 
complicadas  con  los  usuarios,  agradeceras  tener  a la  mano  todas  estas  utilidades 
disponibles. 

En  el  proximo  capitulo,  echaremos  un  vistazo  a una  parte  de  Django  que  necesita 
la  infraestructura  que  proporciona  el  sistema  de  cache,  el  cual  es  una  forma 
conveniente  para  mejorar  el  funcionamiento  y rendimiento  de  tus  aplicaciones. 
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El  sistema  de  Cache 


Los  sitios  Web  estaticos,  en  Ios  que  las  paginas  son  servidas  directamente  por  el 
servidor  Web,  generan  un  gran  escalamiento.  Una  gran  desventaja  en  los  sitios  Web 
dinamicos,  es  precisamente  eso,  que  son  dinamicos.  Cada  vez  que  un  usuario  pide 
una  pagina,  el  servidor  realiza  una  serie  de  calculos  -consultas  a una  base  de  datos, 
renderizado  de  plantillas,  logica  de  negocio  -para  crear  la  pagina  que  el  visitante 
finalmente  ve.  Esto  es  costoso  desde  el  punto  de  vista  del  sobreprocesamiento. 

Para  la  mayoria  de  las  aplicaciones  Web,  esta  sobrecarga  no  es  gran  cosa.  La 
mayoria  de  las  aplicaciones  Web  no  son  el  Washingtonpost  o Pinterest;  son  de  un 
tamano  pequeno  a uno  mediano,  y con  poco  trafico.  Pero  para  los  sitios  con  trafico 
de  medio  a alto  es  esencial  bajar  lo  mas  que  se  pueda  el  costo  de  procesamiento.  He 
aqui  cuando  realizar  un  cache  es  de  mucha  ayuda. 

Colocar  en  cache  algo  significa  guardar  el  resultado  de  un  calculo  costoso  para  que 
no  se  tenga  que  realizar  el  mismo  la  proxima  vez.  Aqui  mostramos  un  pseudocodigo 
explicando  como  podria  funcionar  esto  para  una  pagina  Web  dinamica: 

dada  una  URL,  buscar  esa  paqina  en  la  cache 

si  la  pagina  esta  en  la  cache: 
devolver  la  pagina  en  cache 

si  no: 

generar  la  pagina 

guardar  la  pagina  generada  en  la  cache  (para  la  proxima  vez) 
devolver  la  pagina  generada 

Django  incluye  un  sistema  de  cache  robusto  que  permite  guardar  paginas 
dinamicas  para  que  no  tengan  que  ser  recalculadas  cada  vez  que  se  piden.  Por 
conveniencia,  Django  ofrece  dife rentes  niveles  de  granularidad  de  cache.  Puedes 
dejar  en  cache  el  resultado  de  diferentes  vistas,  solo  las  piezas  que  son  dificiles  de 
producir,  o se  puede  dejar  en  cache  el  sitio  entero. 

Django  tambien  trabaja  muy  bien  con  caches  de  “downstream”,  tales  como  Squid 
y las  caches  de  los  navegadores.  Estos  son  los  tipos  de  cache  que  no  controlas 
directamente  pero  a las  cuales  puedes  proveerles  algunas  pistas  (via  cabeceras  HTTP) 
acerca  de  que  partes  de  tu  sitio  deben  ser  colocadas  en  cache  y como. 

Sigue  leyendo  para  descubrir  como  usar  el  sistema  de  cache  de  Django.  Cuando 
tu  sitio  se  parezca  cada  vez  mas  a Pinterest,  estaras  contento  de  entender  este 
material. 
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Activar  la  Cache 

El  sistema  de  cache  requiere  solo  una  pequena  configuration.  A saber,  tendras  que 
decide  donde  viviran  los  datos  de  tu  cache,  si  es  en  una  base  de  datos,  en  el  sistema 
de  archivos,  o directamente  en  memoria.  Esta  es  una  decision  importante  que  afecta 
el  rendimiento  de  la  cache  (si,  algunos  tipos  de  cache  son  mas  rapidos  que  otros).  La 
cache  en  memoria  generalmente  sera  mucho  mas  rapida  que  la  cache  en  el  sistema 
de  archivos  o la  cache  en  una  base  de  datos,  porque  carece  del  trabajo  de  tocar  los 
mismos. 

Tus  preferencias  acerca  de  la  cache  van  en  la  variable  CACHE  en  el  archivo  de 
configuration.  A continuation  daremos  un  recorrido  por  todos  los  valores  y 
configuraciones  disponibles  que  puedes  usar  para  configurar  la  CACHE. 

Memcached 

Por  mucho,  el  mas  rapido  y eficiente  soporte  nativo  de  cache  para  Django  es 
memcached,  el  cual  es  un  framework  de  cache  basado  enteramente  en  memoria, 
originalmente  desarrollado  para  manejar  grandes  cargas  en  Livejournal 
(http://www.livejournal.com/)y  subsecuentemente  por  Danga  Interactive 
(http://danga.com/).  Es  usado  por  sitios  como  Slashdot  y Wikipedia  para  reducir  el 
acceso  a bases  de  datos  e incrementar  el  rendimiento  dramaticamente. 

Memcached  esta  disponible  libremente  para  descargar.  Corre  como  un  demonio 
y se  le  asigna  una  cantidad  especifica  de  memoria  RAM.  Su  caracteristica  principal  es 
proveer  una  interfaz  - super-liviana-y-rapida  para  anadir,  obtener  y eliminar 
arbitrariamente  datos  en  la  cache.  Todos  los  datos  son  guardados  directamente  en 
memoria,  por  lo  tanto  no  existe  sobrecarga  de  uso  en  una  base  de  datos  o en  el 
sistema  de  archivos. 

Despues  de  haber  instalado  Memcached,  es  necesario  que  instales  alguno  de  los 
adaptadores  disponibles  para  usar  Python  con  Memcached,  los  cuales  no  vienen 
incluidas  con  Django. 

Dichos  adaptadores  pueden  ser  python- memcached  y/o  pylibmc.  Los  cuales 
estan  disponibles  como  modulos  de  Python. 

Para  usar  Memcached  con  Django,  usa  como  BACKEND  a: 

django.core.cache.backends.memcached.MemcachedCache  o 

django.core.cache.backends.memcached.PyLibMCCache  (Dependiendo  de  el 

adaptador  que  hayas  elegido  usar).  Fija  el  valor  de  LOCATION  como  ip:puerto,  donde 
ip  es  la  direction  IP  del  demonio  de  Memcached  y puerto  es  el  puerto  donde 
Memcached  esta  corriendo  o usa  los  valores  unix:path,  donde  path  es  la  ruta  al 
archivo  usado  como  socket  en  unix  por  Memcached. 

En  el  siguiente  ejemplo,  Memcached  esta  corriendo  en  localhost  (127.0.0.1)  en  el 
puerto  11211,  usando  como  dependencia  python- memcached: 

CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. memcached. MemcachedCache', 
'LOCATION':  '127.0.0.1:11211', 

} 

} 


En  el  siguiente  ejemplo,  Memcache  esta  disponible  a traves  del  socket  local  unix, 
que  usa  el  archivo  /tmp/memcached.sock  como  socket,  usando  los  enlaces 
proporcionados  por  python-memcached: 
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CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. memcached.MemcachedCache', 
'LOCATION':  'unix:/tmp/memcached.sock\ 

} 

} 


Una  muy  buena  caracteristica  de  Memcached  es  su  habilidad  de  compartir  la 
cache  en  varios  servidores.  Esto  significa  que  puedes  correr  demonios  de  Memcached 
en  diferentes  maquinas,  y el  programa  seguira  tratando  el  grupo  de  diferentes 
maquinas  como  una  sola  cache,  sin  la  necesidad  de  duplicar  los  valores  de  la  cache 
en  cada  maquina.  Para  sacar  provecho  de  esta  caracteristica  con  Django,  incluye 
todas  las  direcciones  de  los  servidores  en  LOCATION,  separados  por  punto  y coma. 

En  el  siguiente  ejemplo,  la  cache  es  compartida  en  varias  instancias  de 
Memcached  en  las  direcciones  IP  172.19.26.240  y 172.19.26.242,  ambas  en  el  puerto 
11211: 

CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. memcached.MemcachedCache', 
'LOCATION':  [ 

'172.19.26.240:11211', 

'172.19.26.242:11211', 

] 

} 

} 


En  el  siguiente  ejemplo,  la  cache  es  compartida  en  diferentes  instancias  de 
Memcached  corriendo  en  las  direcciones  IP  172.19.26.240  (puerto  11211), 
172.19.126.242  (puerto  11212)  y 172.19.26.244  (puerto  11213): 

CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. memcached.MemcachedCache', 
'LOCATION':  [ 

'172.19.26.240:11211', 

'172.19.26.242:11212', 

'172.19.26.244:11213', 

] 

} 


Una  ultima  observation  acerca  de  Memcached  es  que  la  cache  basada  en 
memoria  tiene  una  importante  desventaja.  Como  los  datos  de  la  cache  son  guardados 
en  memoria,  seran  perdidos  si  los  servidores  se  caen.  Mas  claramente,  la  memoria  no 
es  para  almacenamiento  permanente,  por  lo  tanto  no  te  quedes  solamente  con  una 
cache  basada  en  memoria.  Sin  duda,  ninguno  de  los  sistemas  de  cache  de  Django 
debe  ser  utilizado  para  almacenamiento  permanente  -son  todos  una  solution  para  la 
cache,  no  para  almacenamiento  pero  hacemos  hincapie  aqui  porque  la  cache  basada 
en  memoria  es  unicamente  para  uso  temporal. 
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Cache  en  Base  de  datos 

Para  usar  una  tabla  de  una  base  de  datos  como  cache,  tienes  que  crear  una  tabla  en 
tu  base  de  datos  y apuntar  el  sistema  de  cache  de  Django  a ella. 

Primero,  crea  la  tabla  de  cache  corriendo  el  siguiente  comando: 

python  manage. py  createcachetable  [nombre_tabla_cache] 

Donde  [nombre_tabla_cache]  es  el  nombre  de  la  tabla  a crear.  Este  nombre  puede 
ser  cualquiera  que  desees,  siempre  y cuando  sea  un  nombre  valido  para  una  tabla  y 
que  no  este  ya  en  uso  en  tu  base  de  datos.  Este  comando  crea  una  unica  tabla  en  tu 
base  de  datos  con  un  formato  apropiado  para  el  sistema  de  cache  de  Django. 

Una  vez  que  se  hayas  creado  la  tabla,  usa  la  propiedad  LOCATION  como 
LOCATION:nombre_tabla,  donde  nombre_tabla  es  el  nombre  de  la  tabla  en  la  base 
de  datos  y usa  como  BACKEND  django.core.cache.backends.db.DatabaseCache 
En  el  siguiente  ejemplo,  el  nombre  de  la  tabla  para  el  cache  es  mi_tabla_cache: 

CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. db.DatabaseCache', 

'LOCATION':  'mi_tabla_cache', 

} 

} 


El  sistema  de  cache  usara  la  misma  base  de  datos  especificada  en  el  archivo  de 
configuration.  Por  lo  que  no  podras  usar  una  base  de  datos  diferente,  a menos  que  la 
registres  primero. 


Cache  en  Sistema  de  Archivos 

Para  almacenar  la  cache  en  el  sistema  de  archivos  y almacenar  cada  valor  de  la  cache 
como  un  archivo  separado,  configura  la  propiedad  BACKEND  usando 
django. core.cache.backends.filebased.FileBasedCache  y especificando  en  LOCATION 
el  directorio  en  tu  sistema  de  archivos  que  deberia  almacenar  los  datos  de  la  cache. 

Por  ejemplo,  para  almacenar  los  datos  de  la  cache  en  /var/tmp/django_cache, 
coloca  lo  siguiente: 

CACHES ={ 

'default':  { 

’BACKEND’:  ’django. core. cache. backends. filebased.FileBasedCache’, 
'LOCATION1:  7var/tmp/django_cache', 

} 

} 


Si  usas  Windows,  especifica  la  letra  de  la  unidad  al  comienzo  de  la  ruta  de 
directorios  de  esta  forma: 

CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. filebased.FileBasedCache', 
'LOCATION':  'c:/usuarios/temp', 

} 

} 
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La  ruta  de  directories,  debe  ser  absoluta  -debe  comenzar  con  la  raiz  de  tu  sistema 
de  archivos.  No  importa  si  colocas  una  barra  al  final  de  la  misma. 

Asegurate  que  el  directorio  apuntado  por  esta  propiedad  exista  y que  pueda  ser 
leido  y escrito  por  el  usuario  del  sistema  usado  por  tu  servidor  Web,  para  ejecutarse. 

Continuando  con  el  ejemplo  anterior,  si  tu  servidor  corre  como  usuario  apache, 
asegurate  que  el  directorio  /var/tmp/django_cache  exista  y pueda  ser  leido  y escrito 
por  el  usuario  apache. 

Cada  valor  de  la  cache  sera  almacenado  como  un  archivo  separado  conteniendo 
los  datos  de  la  cache  serializados  (“pickled”),  usando  el  modulo  Python  pickle.  Cada 
nombre  de  archivo  es  una  clave  de  la  cache,  modificado  convenientemente  para  que 
pueda  ser  usado  por  el  sistema  de  archivos. 

Cache  en  Memoria  local 

Si  quieres  usar  la  ventaja  que  otorga  la  velocidad  de  la  cache  en  memoria,  pero  no 
tienes  la  capacidad  de  correr  Memcached,  puedes  optar  por  el  cache  de  memoria- 
local.  Esta  cache  es  por  proceso  y usa  hilos-seguros,  pero  no  es  tan  eficiente  como 
Memcache  dada  su  estrategia  de  bloqueo  simple  y reserva  de  memoria. 

Para  usarla,  usa  como  BACKEND  a 
django.core.cache.backends.locmem.LocMemCache.  Por  ejemplo: 

CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. locmem.LocMemCache', 

'LOCATION':  'unico-proceso' 

} 

} 


El  atributo  LOCATION  de  la  cache  es  usada  para  identificar  de  forma  individual  el 
almacenamiento  de  la  memoria.  Si  utilizas  unicamente  un  proceso  puedes  omitir 
LOCATION;  sin  embargo  si  utilizas  mas  de  uno,  necesitas  asignar  un  nombre  a al 
menos  uno  de  los  procesos  para  mantenerlos  separados. 

Observa  que  cada  proceso  tendra  su  propia  instancia  de  cache  privada,  lo  cual 
significa  que  no  es  posible  el  proceso  cruzado  de  cache.  Esto  obviamente  tambien 
significa  que  la  memoria  local  de  cache  no  es  particularmente  muy  eficiente,  asi  que 
no  es  una  buena  option  para  usar  en  ambientes  de  production.  Es  recomendable 
solo  para  desarrollo. 

Cache  personalizada 

A pesar  de  que  Django  incluye  soporte  para  el  uso  de  un  buen  numero  de  sistemas  de 
cache  fuera  de  la  caja,  algunas  veces  puede  que  quieras  usar  un  almacenamiento  de 
cache  personalizado,  para  fines  especificos. 

Para  usar  almacenamiento  externo  de  cache  con  Django,  usa  la  ruta  de 
importaciones  de  Python  como  BACKEND  y carga  la  configuration  de  la  cache  asi: 

CACHES ={ 

'default':  { 

'BACKEND':  'ruta.a. backend', 

} 

} 


Si  estas  construyendo  tu  propio  sistema  de  cache,  puedes  usar  el  sistema  de 
almacenamiento  de  caches  de  Django  como  referencia  para  implementar  el  tuyo. 
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Puedes  encontrar  el  codigo  fuente  en  el  directorio  ubicado  en: 
django/core/cache/backends/ 

Cache  tonta  (para  desarrollo) 

Finalmente,  Django  incluye  una  cache  tonta  formalmente  llamada:  “dummy”  que  no 
realiza  cache;  solo  implementa  la  interfaz  de  cache  sin  realizar  ninguna  action. 

Esta  es  util  cuando  tienes  un  sitio  en  produccion  que  usa  mucho  cache  en  varias 
partes  y en  un  entorno  de  desarrollo /prueba  en  el  cual  no  quieres  hacer  cache.  En  ese 
caso,  usa  BACKEND  como  django.core.cache.backends.dummy.DummyCache  en  el 
archivo  de  configuracion  para  tu  entorno  de  desarrollo,  por  ejemplo: 

CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. dummy. DummyCache', 

} 

} 


Como  resultado  de  esto,  tu  entorno  de  desarrollo  no  usara  cache,  pero  tu  entorno 
de  produccion  si  lo  hara. 


Argumentos  de  cache 

Cada  tipo  de  cache  puede  recibir  argumentos  adicionales  para  controlar  el 
comportamiento  de  la  cache.  Estos  son  dados  como  una  clave  adicional  a la 
configuracion  de  CACHES.  Los  argumentos  validos  son  los  siguientes: 

• TIMEOUT:  El  tiempo  de  vida  por  omision,  en  segundos,  que  usara  la  cache. 
Este  argumento  tomara  el  valor  de  300  segundos  (5  minutos)  si  no  se  lo 
especifica. 

Tambien  puedes  especificar  TIMEOUT  como  None,  por  defecto  la  clave  de  la 
cache  nunca  expira. 

• OPTIONS:  Cualquier  option  que  se  necesite  pasar  a la  cache.  La  lista  de 
opciones  validas  dependent  de  cada  backend,  por  lo  que  el  almacenamiento 
de  cache  proporcionado  por  librerias  de  terceros,  sera  pasado  con  sus 
opciones  directamente  bajo  la  cache  de  la  libreria. 

Los  almacenamientos  de  cache  que  implementan  sus  propias  estrategias  de 
selection  (por  ejemplo:  en  memoria,  archivos  y en  base  de  datos)  respetan  las 
siguientes  opciones: 

• MAX_ENTRIES:  Para  la  cache  de  memoria  local,  y la  cache  de  base  de  datos, 
es  el  numero  maximo  de  entradas  permitidas  en  la  cache  a partir  del  cual  los 
valores  mas  viejos  seran  eliminados.  Tomara  un  valor  de  300  si  no  se  lo 
especifica. 

• CULL_FREQUENCY:  La  proportion  de  entradas  que  seran  sacrificadas 
cuando  la  cantidad  de  MAX_ENTRIES  es  alcanzada.  La  proportion  real  es 
1/CULL_FREQUENCY,  si  quieres  sacriflcar  la  mitad  de  las  entradas  cuando  se 
llegue  a una  cantidad  de  MAX_ENTRIES  coloca  CULL_FREQUENCY=2.  Este 
argumento  tomara  un  valor  de  3 si  no  se  especifica. 
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Un  valor  de  0 para  CULL_FREQUENCY  significa  que  toda  la  cache  sera 
limpiada  cuando  se  llegue  a una  cantidad  de  entradas  igual  a MAX_ENTRIES. 
Esto  hace  que  el  proceso  de  limpieza  de  la  cache  sea  mucho  mas  rapido,  con 
el  costo  de  perder  mas  datos  de  la  cache.  Este  argumento  tomara  un  valor  de  3 
si  no  se  especifica. 

• KEY_PREFIX:  Una  cadena  que  automaticamente  incluye  (agrega  por  default) 
todas  las  claves  de  caches  usadas  por  el  servidor  Django. 

• VERSION  El  numero  de  version  de  las  claves  de  cache  generadas  por  el 
servidor  Django. 

• KEY_FUNCTION:  Una  cadena  que  contiene  la  ruta  (usando  el  punto)  a la 
funcion  que  define  la  forma  en  que  esta  compuesta  el  prelijo,  la  version  y la 
clave,  en  la  clave  de  la  cache  final. 

En  este  ejemplo,  usamos  un  “archivo”  como  almacenamiento  de  cache 
(BACKEND),  configurado  con  un  valor  de  tiempo  de  60  segundos  (TIMEOUT)  y con 
una  capacidad  maxima  (MAX_ENTRIES)  de  1000  items: 

CACHES ={ 

'default':  { 

'BACKEND':  'django. core. cache. backends. filebased.FileBasedCache', 

'LOCATION':  7var/tmp/django_cache', 

'TIMEOUT':  60, 

'OPTIONS':  { 

'MAX_ENTRIES':  1000 

} 

} 

} 


Tanto  los  argumentos  desconocidos,  asi  como  los  valores  invalidos  de  argumentos 
conocidos  son  ignorados  silenciosamente. 


La  cache  por  sitio 

Una  vez  que  hayas  especificado  CACHE,  la  manera  mas  simple  de  usar  la  cache  es 
colocar  en  cache  el  sitio  entero.  Esto  significa  que  cada  pagina  que  no  tenga 
parametros  GET  o POST  sera  puesta  en  cache  por  un  cierto  periodo  de  tiempo  la 
primera  vez  que  sean  pedidas. 

Para  activar  la  cache  por  sitio  agrega: 

' dj  ango . middleware  .cache . Cache  Middleware ' y 

django. middleware.cache.FetchFromCacheMiddleware  a la  propiedad 
MIDDLEWARE_CLASSES,  como  en  el  siguiente  ejemplo: 

MIDDLEWARE_CLASSES  = ( 

'django.  middleware. cache.  UpdateCacheMiddleware', 

'django.  middleware,  common.  CommonMiddleware', 

'django.  middleware. cache.  FetchFromCacheMiddleware', 

) 
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Nota:  El  orden  de  MIDDLEWARE_CLASSES  importa.  Mira  la  section  “Orden  de 
MIDDLEWARE_CLASSES”  mas  adelante  en  este  capltulo. 


Luego,  agrega  las  siguientes  propiedades  en  el  archivo  de  configuration  de 
Django: 

• CACHE  MIDDLEWARE^ALIAS:  El  nombre  del  alias  para  usar  como 
almacenaje. 

• CACHE  MIDDLEWARE_SECONDS:  El  tiempo  en  segundos  que  cada  pagina 
sera  mantenida  en  la  cache. 

• CACHE  MIDDLEWARE_KEY_PREFIX:  Si  la  cache  es  compartida  a traves  de 
multiples  sitios  usando  la  misma  instalacion  Django,  coloca  esta  propiedad 
como  el  nombre  del  sitio,  u otra  cadena  que  sea  unica  para  la  instancia  de 
Django,  para  prevenir  colisiones.  Usa  una  cadena  vatia  si  no  te  interesa. 

La  cache  middleware  coloca  en  cache  cada  pagina  que  no  tenga  parametros  GET 
o POST.  Esto  significa  que  si  un  usuario  pide  una  pagina  y pasa  parametros  GET  en  la 
cadena  de  consulta,  o pasa  parametros  POST,  la  cache  middleware  no  intentara 
obtener  la  version  en  cache  de  la  pagina.  Si  intentas  usar  la  cache  por  sitio  ten  esto  en 
mente  cuando  disenes  tu  aplicacion;  no  uses  URLs  con  cadena  de  consulta,  por 
ejemplo,  a menos  que  sea  aceptable  que  tu  aplicacion  no  coloque  en  cache  esas 
paginas. 

Finalmente,  nota  que  CacheMiddleware  automaticamente  coloca  unos  pocos 
encabezados  en  cada  ElttpResponse: 

■ Coloca  el  encabezado  Last-Modified  con  el  valor  actual  de  la  fecha  y hora 
cuando  una  pagina  (aun  no  en  cache)  es  requerida. 

■ Coloca  el  encabezado  Expires  con  el  valor  de  la  fecha  y hora  mas  el  tiempo 
definido  en  CACHE_MIDDLEWARE_SECONDS. 

■ Coloca  el  encabezado  Cache-Control  para  otorgarle  una  vida  maxima  a la 
pagina,  como  se  especiflca  en  CACE1E_MIDDLEWARE_SEC0NDS. 


Cache  para  vistas 

Una  forma  mas  granular  de  usar  el  framework  de  cache  es  colocar  en  cache  la  salida 
de  las  diferentes  vistas.  Esto  tiene  el  mismo  efecto  que  la  cache  por  sitio  (incluyendo 
la  omision  de  colocar  en  cache  los  pedidos  con  parametros  GET  y POST).  Se  aplica  a 
cualquier  vista  que  tu  especifiques,  en  vez  de  aplicarse  al  sitio  entero. 

Haz  esto  usando  un  decorador,  que  es  un  wrapper  de  la  funcion  de  la  vista  que 
altera  su  comportamiento  para  usar  la  cache.  El  decorador  de  cache  por  vista  es 
llamado  cache_page  y se  encuentra  en  el  modulo  django.views. decorators. cache,  por 
ejemplo: 
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from  django. views. decorators. cache  import  cache_page 

def  mi_vista(request,  param): 

# ... 

mi_vista  = cache_page(mi_vista,  60  * 15) 


De  otra  manera,  si  estas  usando  alguna  version  de  Python,  superior  a la  2.7, 
puedes  usar  un  decorador.  El  siguiente  ejemplo  es  equivalente  al  anterior: 

from  django. views. decorators. cache  import  cache_page 

@cache_page(60  * 15) 
def  mi_vista(request,  param): 

# ... 

cache_page  recibe  un  unico  argumento:  el  tiempo  de  vida  en  segundos  de  la  cache. 
En  el  ejemplo  anterior,  el  resultado  de  mi_vista()  estara  en  cache  unos  15  minutos. 
(Toma  nota  de  que  lo  hemos  escrito  como  60  * 15  para  que  sea  entendible.  60  * 15 
sera  evaluado  como  900  -que  es  igual  a 15  minutos  multiplicados  por  60  segundos 
cada  minuto.) 

La  cache  por  vista,  como  la  cache  por  sitio,  es  indexada  independientemente  de  la 
URL.  Si  multiples  URLs  apuntan  a la  misma  vista,  cada  URL  sera  puesta  en  cache 
separadamente. 

Continuando  con  el  ejemplo  de  mi_vista,  si  tu  URLconf  se  ve  como: 
urlpatterns  = [ 

url(r'Afoo/([0-9]{l,2})/$',  mi_vista), 

] 


Los  pedidos  a /foo/1/  y a /foo/23/  seran  puestos  en  cache  separadamente,  como 
es  de  esperar.  Pero  una  vez  que  una  misma  URL  es  pedida  (p.e.  /foo/23/),  los 
siguientes  pedidos  a esa  URL  utilizaran  la  cache. 

cache_page  toma  un  argumento  de  clave  opcional:  llamado  cache,  el  cual  puede 
usarse  directamente  en  el  decorador  especificando  la  cache  (tomada  de  el  archivo  de 
configuracion  de  la  variable  CACHE)  para  cachear  la  vista.  Por  defecto,  el  cache  para 
usar  sera  especificado  con  cualquier  cache  que  queramos,  por  ejemplo: 

@cache_page(60  * 15,  cache="cache_especial") 

def  mi_vista(request): 

algun_metodo() 

Tambien  es  posible  sobrescribir  el  prefijo  de  la  cache  en  la  vista.  El  decorador 
cache_page  toma  un  argumento  de  clave  key_prefix,  el  cual  trabaja  de  la  misma 
forma  que  la  configuracion  CACHE_MIDDLEWARE_KEY_PRELIX  en  el  middleware. 
Puede  usarse  de  la  siguiente  forma: 

@cache_page(60  * 15,  key_prefix="sitiol") 

def  mi_vista(request): 

algun_metodo() 
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Las  dos  configuraciones  pueden  ser  combinadas.  Si  especificas  cache  y key_prefix 
puedes  traer  todas  las  configuraciones  en  la  peticion  usando  alias  en  la  cache,  solo 
que  esto  sobrescribira  el  argumento  key_prefix. 

Cache  por  vista  en  la  URLconf 

Los  ejemplos  en  la  seccion  anterior  incrustan  la  cache  en  las  vistas,  porque  el 
decorador  cache_page  modifica  la  funcion  mi_vista  en  la  misma  vista.  Este  enfoque 
acopla  tu  vista  con  el  sistema  de  cache,  lo  cual  no  es  lo  ideal  por  varias  razones.  Por 
ejemplo,  puede  que  quieras  rehusar  las  funciones  de  la  vista  en  otro  sitio  sin  cache,  o 
puede  que  quieras  distribuir  las  vistas  a gente  que  quiera  usarlas  sin  que  sean 
colocadas  en  la  cache.  La  solution  para  estos  problemas  es  especificar  la  cache  por 
vista  en  URLconf  en  vez  de  especificarla  junto  a las  vistas  mismas. 

Hacer  eso  es  muy  facil:  simplemente  envuelve  la  funcion  de  la  vista  con 
cache_page  cuando  hagas  referencia  a ella  en  la  URLconf.  Aqui  el  URLconf  como 
estaba  antes: 

urlpatterns  = [ 

url(r'Afoo/([0-9]{l,2})/$',  mi_vista), 

] 


Ahora  la  misma  cosa  con  la  funcion  mi_vista  usando  el  decorador  cache_page: 
from  django. views. decorators. cache  import  cache_page 
urlpatterns  = [ 

url(r'Afoo/([0-9]{l,2})/$',  cache_page(60  * 15)(mi_vista)), 

] 


Si  tomas  este  enfoque  no  olvides  de  importar  cache_page  dentro  de  tu  URLconf. 

La  API  de  cache  de  bajo  nivel 


Algunas  veces,  colocar  en  cache  una  pagina  entera  no  te  hace  ganar  mucho  y es,  de 
hecho,  un  inconveniente  excesivo. 

Quizas,  por  ejemplo,  tu  sitio  incluye  una  vista  cuyos  resultados  dependen  de 
diversas  consultas  costosas,  lo  resultados  de  las  cuales  cambian  en  intervalos 
diferentes.  En  este  caso,  no  seria  ideal  usar  la  pagina  entera  en  cache  que  la  cache  por 
sitio  o por  vista  ofrecen,  porque  no  querras  guardar  en  cache  todo  el  resultado  (ya 
que  los  resultados  cambian  frecuentemente),  pero  querras  guardar  en  cache  los 
resultados  que  rara  vez  cambian. 

Para  casos  como  este,  Django  expone  una  simple  API  de  cache  de  bajo  nivel,  la 
cual  vive  en  el  modulo  django. core. cache.  Puedes  usar  la  API  de  cache  de  bajo  nivel 
para  almacenar  los  objetos  en  la  cache  con  cualquier  nivel  de  granularidad  que  te 
guste.  Puedes  colocar  en  la  cache  cualquier  objeto  Python  que  pueda  ser  serializado 
de  forma  segura:  strings,  diccionarios,  listas  de  objetos  del  modelo,  y demas.  (La 
mayoria  de  los  objetos  comunes  de  Python  pueden  ser  serializados;  revisa  la 
documentation  de  Python  para  mas  information  acerca  de  serializado n). 

Aqui  vemos  como  importar  la  API: 
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»>  from  django. core. cache  import  cache 

La  interfaz  basica  es  setfkey,  value,  timeout)  y get(key): 

»>  cache. set('mi_clave\  'jHola  Mundo!',  30) 

»>  cache. get('mi_clave') 

' jHola  Mundo!' 

El  argumento  timeout  es  opcional  y obtiene  el  valor  del  argumento  timeout  de  la 
variable  CACHE,  explicado  anteriormente,  si  no  se  lo  especifica. 

Si  el  objeto  no  existe  en  la  cache,  o el  sistema  de  cache  no  se  puede  alcanzar, 
cache. get()  devuelve  None: 

# Espera  30  segundos  por 'mi_clave'  para  que  expire... 

»>  cache. get('mi_clave') 

None 

»>  cache. get('otra_clave') 

None 

Te  recomendamos  que  no  almacenes  el  valor  literal  None  en  la  cache,  porque  no 
podras  distinguir  entre  tu  valor  None  almacenado  y el  valor  que  devuelve  la  cache 
cuando  no  encuentra  un  objeto. 

cache.getO  puede  recibir  un  argumento  por  omision.  Esto  especifica  que  valor 
debe  devolver  si  el  objeto  no  existe  en  la  cache: 

»>  cache. get('mi_clave',  ha  expirado') 

'ha  expirado' 

Para  obtener  multiples  valores  de  la  cache  de  una  sola  vez,  usa  cache.get_many(). 
Si  al  sistema  de  cache  le  es  posible,  get_many()  tocara  la  cache  solo  una  vez,  al 
contrario  de  tocar  la  cache  por  cada  valor.  get_many()  devuelve  un  diccionario  con 
todas  las  claves  que  has  pedido  que  existen  en  la  cache  y todavia  no  han  expirado: 

»>  cache. set('a',  1) 

»>  cache. set('b',  2) 

»>  cache. set('c',  3) 

»>  cache. get_many(['a',  'b',  c']) 

Si  una  clave  no  existe  o ha  expirado,  no  sera  incluida  en  el  diccionario.  Lo 
siguiente  es  una  continuation  del  ejemplo  anterior: 

»>  cache. get_many(['a',  'b',  c',  d']) 

{'a':  1,  'b':  2,  'c':  3} 

Finalmente,  puedes  eliminar  claves  explicitamente  con  cache.deleteO.  Esta  es  una 
manera  facil  de  limpiar  la  cache  para  un  objeto  en  particular: 

»>  cache. delete('a') 

cache.deleteO  no  tiene  un  valor  de  retorno,  y funciona  de  la  misma  manera  si 
existe  o no  un  valor  en  la  cache. 
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Caches  downstream 

Este  capitulo  se  ha  enfocado  en  la  cache  de  tus  propios  datos.  Pero  existe  otro  tipo  de 
cache  que  es  muy  importante  para  los  desarrolladores  web:  la  cache  realizada  por  los 
downstream.  Estos  son  sistemas  que  colocan  en  cache  paginas  aun  antes  de  que  estas 
sean  pedidas  a tu  sitio  Web. 

Aqul  hay  algunos  ejemplos  de  caches  para  downstream: 

• Tu  ISP  puede  tener  en  cache  algunas  paginas,  si  tu  pides  una  pagina  de 
http://example.com/,  tu  ISP  te  enviara  la  pagina  sin  tener  que  acceder  a 
example.com  directamente.  Los  responsables  de  example.com  no  tienen  idea 
que  esto  pasa;  el  ISP  se  coloca  entre  example.com  y tu  navegador,  manejando 
todo  lo  que  se  reliera  a cache  transparentemente. 

• Tu  sitio  en  Django  puede  colocarse  detras  de  un  cache  proxy,  como  Squid 
Web  Proxy  Cache  ((f)  http:://www.squid-cache.org/),  que  coloca  en  cache 
paginas  para  un  mejor  rendimiento.  En  este  caso,  cada  pedido  sera 
controlado  por  el  proxy  antes  que  nada,  y sera  pasado  a tu  aplicacion  solo  si  es 
necesario. 

• Tu  navegador  tambien  pone  paginas  en  un  cache.  Si  una  pagina  Web  envia 
unos  encabezados  apropiados,  tu  navegador  usara  su  copia  de  la  cache  local 
para  los  siguientes  pedidos  a esa  pagina,  sin  siquiera  hacer  nuevamente 
contacto  con  la  pagina  web  para  ver  si  esta  ha  cambiado. 

La  cache  de  downstream  es  un  gran  beneficio,  pero  puede  ser  peligroso.  El 
contenido  de  muchas  paginas  Web  pueden  cambiar  segun  la  autenticacion  que  se 
haya  realizado  u otras  variables,  y los  sistemas  basados  en  almacenar  en  cache  segun 
la  URL  pueden  exponer  datos  incorrectos  o delicados  a diferentes  visitantes  de  esas 
paginas. 

Por  ejemplo,  digamos  que  manejas  un  sistema  de  e-mail  basado  en  Web,  el 
contenido  de  la  “bandeja  de  entrada”  obviamente  depende  de  que  usuario  este 
logueado.  Si  el  ISP  hace  caching  de  tu  sitio  ciegamente,  el  primer  usuario  que  ingrese 
al  sistema  compartira  su  bandeja  de  entrada,  que  esta  en  cache,  con  los  demas 
usuarios  del  sistema.  Eso,  definitivamente  no  es  bueno. 

Afortunadamente,  el  protocolo  E1TTP  provee  una  solution  a este  problema. 
Existen  un  numero  de  encabezados  E1TTP  que  indican  a las  cache  de  downstream 
que  diferencien  sus  contenidos  de  la  cache  dependiendo  de  algunas  variables,  y para 
que  algunas  paginas  particulares  no  se  coloquen  en  cache.  Veremos  algunos  de  estos 
encabezados  en  las  secciones  que  siguen. 

Usar  el  encabezado  Vary 

El  encabezado  Vary  define  cuales  encabezados  deberia  tener  en  cuenta  un  sistema  de 
cache  cuando  construye  claves  de  su  cache.  Por  ejemplo,  si  el  contenido  de  una 
pagina  Web  depende  de  las  preferencias  de  lenguaje  del  usuario,  se  dice  que  la 
pagina  “varia  segun  el  lenguaje”. 

Por  omision,  el  sistema  de  cache  de  Django  crea  sus  claves  de  cache  usando  la  ruta 
que  se  ha  requerido  (p.e.:  "/stories/2005/jun/23/bank_robbed/").  Esto  significa  que 
cada  pedido  a esa  URL  usara  la  misma  version  de  cache,  independientemente  de  las 
caracteristicas  del  navegador  del  cliente,  como  las  cookies  o las  preferencias  del 
lenguaje.  Sin  embargo,  si  esta  pagina  produce  contenidos  diferentes  basandose  en 
algunas  cabeceras  del  request-como  las  cookies,  el  lenguaje,  o el  navegador- 
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necesitaras  usar  el  encabezado  Vary  para  indicarle  a la  cache  que  esa  pagina  depende 
de  esas  cosas. 

Para  hacer  esto  en  Django,  usa  el  decorador  vary_on_headers  como  sigue: 

from  django. views. decorators. vary  import  vary_on_headers 

@vary_on_headers('User-Agent') 
def  mi_vista(request): 

# ... 

En  este  caso,  el  mecanismo  de  cache  (como  middleware)  colocara  en  cache  una 
version  distinta  de  la  pagina  para  cada  tipo  de  user-agent. 

La  ventaja  de  usar  el  decorador  vary_on_headers  en  vez  de  fijar  manualmente  el 
encabezado  Vary  (usando  algo  como  response  ['Vary']  = 'user-agent')  es  que  el 
decorador  agrega  al  encabezado  Vary  (el  cual  podria  ya  existir),  en  vez  de  fijarlo  desde 
cero  y potencialmente  sobrescribir  lo  que  ya  habia  ahi. 

Puedes  pasar  multiples  encabezados  a vary_on_headers(): 

@vary_on_headers('User-Agent',  'Cookie') 
def  mi_vista(request): 

# ... 

Esto  le  dice  a la  cache  de  downstream  que  diferencie  ambos,  lo  que  significa  que 
cada  combination  de  una  cookie  y un  navegador  obtendran  su  propio  valor  en  cache. 
Por  ejemplo,  un  pedido  con  navegador  Mozilla  y una  cookie  con  el  valor  foo=bar  sera 
considerada  diferente  a un  pedido  con  el  navegador  Mozilla  y una  cookie  con  el  valor 
foo=ham. 

Como  las  variaciones  con  las  cookies  son  tan  comunes  existe  un  decorador 
vary_on_cookie.  Las  siguientes  dos  vistas  son  equivalentes: 

@vary_on_cookie 
def  mi_vista(request): 

# ... 

@vary_on_headers('Cookie') 
def  mi_vista(request): 

# ... 

El  encabezado  que  le  pasas  a vary_on_headers  no  diferencia  mayusculas  de 
minusculas;  "User -Agent"  es  lo  mismo  que  "user-agent". 

Tambien  puedes  usar  django.utils.cache.patch_vary_headers  como  funcion  de 
ayuda.  Esta  funcion  fija  o anade  al  Vary  header,  por  ejemplo: 

from  django. utils. cache  import  patch_vary_headers 

def  mi_vista(request): 

# ... 

response  = render_to_response('template_name',  context) 
patch_vary_headers(response,  ['Cookie']) 
return  response 

patch_vary_headers  obtiene  una  instancia  de  HttpResponse  como  su  primer 
argumento  y una  lista/tupla  de  nombres  de  encabezados,  sin  diferenciar  mayusculas 
de  minusculas,  como  su  segundo  argumento. 
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Controlando  el  cache:  usando  otros  Encabezados 


Otro  problema  con  la  cache  es  la  privacidad  de  los  datos  y donde  deberian 
almacenarse  los  datos  cuando  se  hace  un  vuelco  de  la  cache. 

El  usuario  generalmente  se  enfrenta  con  dos  tipos  de  cache:  su  propia  cache  de  su 
navegador  (una  cache  privada)  y la  cache  de  su  proveedor  (una  cache  publica).  Una 
cache  publica  es  usada  por  multiples  usuarios  y controlada  por  algunos  otros.  Esto 
genera  un  problema  con  datos  sensibles-no  quieres  que,  por  ejemplo,  el  numero  de 
tu  cuenta  bancaria  sea  almacenado  en  una  cache  publica.  Por  lo  que  las  aplicaciones 
Web  necesitan  una  manera  de  indicarle  a la  cache  cuales  datos  son  privados  y cuales 
son  publicos. 

La  solution  es  indicar  que  la  copia  en  cache  de  una  pagina  es  “privada”.  Para 
hacer  esto  en  Django  usa  el  decorador  de  vista  cache_control: 

from  django. views. decorators. cache  import  cache_control 

@cache_control(private=True) 
def  mi_vista(request): 

# ... 

Este  decorador  se  encarga  de  enviar  los  encabezados  E1TTP  apropiados  detras  de 
escena. 

Nota  que  el  control  de  configuraciones  de  cache  “privado”  y “publico”  es 
mutuamente  excluyente.  El  decorador  se  asegura  que  la  directiva  “publico”  sea 
removida  si  se  encuentra  configurado  como  “privado”  (y  viceversa).  Un  ejemplo  del 
uso  de  estas  dos  directivas,  puede  ser  un  sitio  de  un  blog  que  ofrece  entradas  publicas 
y privadas.  Las  entradas  publicas  pueden  ser  cacheadas  en  la  cache  compartida.  El 
siguiente  codigo  usa  django.utils.cache.patch_cache_control()  para  manualmente 
modificar  el  control  de  las  cabeceras  de  la  cache  (Es  internamente  llamado  por  el 
decorador  cache_control). 

from  django. views. decorators. cache  import  patch_cache_control 
from  django. views. decorators. vary  import  vary_on_cookie 

@vary_on_cookie 

def  lista_de  entradas_blog(request): 
if  request. user. is_anonymous(): 

response  = render_only_public_entries() 
patch_cache_control(response,  public=  ) 
else: 

response  = render_private_and_public_entries(request.user) 
patch_cache_control(response,  private=  ) 

return  response 


Existen  otras  pocas  maneras  de  controlar  los  parametros  de  cache.  Por  ejemplo, 
HTTP  permite  a las  aplicaciones  hacer  lo  siguiente: 

■ Definir  el  tiempo  maximo  que  una  pagina  debe  estar  en  cache. 

■ Especificar  si  una  cache  deberfa  comprobar  siempre  la  existencia  de  nuevas 
versiones,  entregando  unicamente  el  contenido  de  la  cache  cuando  no 
hubiesen  cambios.  (Algunas  caches  pueden  entregar  contenido  aun  si  la 


324  CAPITULO  1 5 EL  SISTEMA  DE  CACHE 


pagina  en  el  servidor  ha  cambiado,  simplemente  porque  la  copia  en  cache 
todavia  no  ha  expirado.) 

Django,  utiliza  el  decorador  cache_control  para  especificar  estos  parametros  de  la 
cache.  En  el  siguiente  ejemplo,  cache_control  le  indica  a la  cache  revalidarse  en  cada 
acceso  y almacenar  versiones  en  cache  hasta  por  3.600  segundos: 

from  django. views. decorators. cache  import  cache_control 

@cache_control(must_revalidate=True,  max_age=3600) 
def  mi_vista(request): 


Cualquier  directiva  Cache-Control  de  HTTP  valida  es  valida  en  cache_control(). 
Aqui  hay  una  lista  completa: 

■ public=True 

■ private=True 

■ no_cache=True 

■ no_transform=True 

■ must_revalidate=True 

■ proxy_revalidate=True 

■ max_age=num_seconds 

■ s_maxage=num_seconds 


Tip:  Para  una  explication  de  las  directivas  Cache-Control  de  HTTP,  consulta  las 
especificaciones  en  (f)  http://www.w3.org/Protocols/rfc2616/rfc2616- 
secl4.html#secl4.9. 


Nota:  El  middleware  de  caching  ya  fija  el  encabezado  max-age  con  el  valor  de 
CACHE_MIDDLEWARE_SETTINGS.  Si  utilizas  un  valor  propio  de  max_age  en  un 
decorador  cache_control,  el  decorador  tendra  precedencia,  y los  valores  del 
encabezado  seran  fusionados  correctamente. 


Si  quieres  usar  cabeceras  para  desactivar  el  cache  por  completo,  usa  el  decorador 
never_cache  del  paquete  django.views. decorators. cache.never_cache  en  una  vista,  a 
la  que  le  quieras  agregar  la  cabecera,  para  asegurarte  que  la  respuesta  no  sea 
cacheada  por  el  navegador  u otros  caches.  Por  ejemplo: 

from  django. views. decorators. cache  import  never_cache 

@never_cache 
def  mi_vista(request): 

# ... 


325 


CAPITULO  15  EL  SISTEMA  DE  CACHE 


Otras  optimizaciones 


Django  incluye  otras  piezas  de  middleware  que  pueden  ser  de  ayuda  para  optimizar 
el  rendimiento  de  tus  aplicaciones: 

■ django.middleware.http.ConditionalGetMiddleware  agrega  soporte  para 
navegadores  modernos  para  condicionar  respuestas  GET  basadas  en  los 
encabezados  ETag  y Las-Modified. 

■ django.middleware.gzip.GZipMiddleware  comprime  las  respuestas  para  todos 
los  navegadores  modernos,  ahorrando  ancho  de  banda  y tiempo  de 
transferencia. 

Orden  de  MIDDLEWARE  CLASSES 


Si  utilizas  CacheMiddleware,  es  importante  colocarlas  en  el  lugar  correcto  dentro  de 
la  propiedad  MIDDLEWARE_CLASSES,  porque  el  middleware  de  cache  necesita 
conocer  los  encabezados  por  los  cuales  cambiar  el  almacenamiento  en  la  cache. 

Coloca  el  CacheMiddleware  despues  de  cualquier  middleware  que  pueda  agregar 
algo  al  encabezado  Vary,  incluyendo  los  siguientes: 

• SessionMiddleware,  que  agrega  Cookie 

• GZipMiddleware,  que  agrega  Accept-Encoding 

• LocaleMiddleware  que  agrega  Accept-Language 


^Que  sigue? 


Django  incluye  un  numero  de  paquetes  opcionales.  Elemos  cubierto  algunos  de  los 
mismos:  como  el  sistema  de  administracion  en  el  capltulo  6,  el  marco  de 
sesiones/usuarios  del  capltulo  14. 

El  proximo  capltulo  cubre  el  resto  de  paquetes  incluidos  en  el  modulo  “contrib”, 
que  provee  una  cantidad  interesante  de  herramientas  disponibles;  que  pueden  hacer 
mas  facil  tu  vida,  no  querras  perderte  ninguno  de  ellos. 


CAPITULO  16 


El  paquete  django.contrib 


Una  de  las  muchas  fortalezas  de  Python,  es  su  filosofla  de  baterias  incluidas. 

Cuando  instalas  Python,  este  viene  con  una  amplia  biblioteca  de  paquetes  que 
puedes  comenzar  a usar  inmediatamente,  sin  necesidad  de  descargar  nada  mas. 

Django  trata  de  seguir  esa  misma  filosofla,  e incluye  su  propia  biblioteca  estandar 
de  paquetes  utiles  para  realizar  las  tareas  mas  comunes  del  desarrollo  web.  Este 
capitulo  cubre  la  coleccion  de  agregados,  agrupados  en  el  paquete  llamado 
django.contrib. 


La  biblioteca  estandar  de  Django 


La  biblioteca  estandar  de  Django  se  localiza  en  el  paquete  django.contrib.  Dentro  de 
cada  sub -paquete  hay  una  pieza  aislada  de  funcionalidad  lista  para  agregar.  Estas 
piezas  no  estan  necesariamente  relacionadas,  pero  algunos  sub-paquetes  de 
django.contrib  requieren  de  otros  paquetes. 

No  hay  grandes  requerimientos  para  los  tipos  de  funcionalidad  que  hay  en 
django.contrib.  Algunos  de  los  paquetes  incluyen  modelos  (y  por  lo  tanto  requieren 
que  instales  sus  tablas  en  tu  base  de  datos),  otros  consisten  solamente  de  middleware 
o de  etiquetas  de  plantillas  ( template  tags). 

La  unica  caracteristica  en  comun  de  todos  los  paquetes  de  django.contrib  es  la 
siguiente:  si  borraras  dicho  paquete  por  completo,  seguirias  pudiendo  usar  las 
capacidades  fundamentales  de  Django  sin  problemas.  Cuando  los  desarrolladores  de 
Django  agregan  una  nueva  funcionalidad  al  framework,  emplean  esa  regia  de  oro  al 
decidir  en  donde  va  a residir  la  nueva  funcionalidad,  si  en  django.contrib,  o en  algun 
otro  lugar. 

django.contrib  consiste  de  los  siguientes  paquetes: 

• admin:  el  sitio  automatico  de  administration.  Consulta  el  capitulo  6. 

• admindocs:  La  auto  documentation  para  el  sitio  administrativo. 

• auth:  el  framework  de  autenticacion  de  Django.  Consulta  el  capitulo  14. 

• contenttypes:  un  framework  para  conectar  “tipos”  de  contenido,  en  que  cada 
modelo  de  Django  instalado  es  un  tipo  de  contenido  aislado.  Este  framework 
es  usado  internamente  por  otras  aplicaciones  “contrib”,  y esta  especialmente 
enfocada  a los  desarrolladores  de  Django  muy  avanzados.  Dichos 
desarrolladores  pueden  hallar  mas  information  sobre  esta  aplicacion,  leyendo 
el  codigo  fuente  que  esta  en  django/ contrib /contenttypes/. 
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• csrf:  protection  ante  un  ataque  de  falsification  de  petition  en  sitios  cruzados, 
en  ingles  Cross-Site  Request  Forgery  (CSRF).  Consulta  la  seccion  titulada 
“Protection  contra  CSRF”  mas  adelante. 

• flatpages:  un  framework  para  administrar  contenido  F1TML  simple,  “piano”, 
dentro  de  la  base  de  datos.  Consulta  la  seccion  titulada  “Flatpages”  mas 
adelante. 

• humanize:  un  conjunto  de  filtros  de  plantillas  Django,  utiles  para  darle  un 
“toque  de  humanidad”  a los  datos.  Consulta  la  seccion  titulada 
“Flumanizando  datos”  mas  adelante. 

• gis:  Extencion  para  Django  que  provee  soporte  para  GIS  (Sistema  de 
Information  Geografica).  Permite  a los  modelos  de  Django,  por  ejemplo 
almacenar  datos  geograficos  y optimizar  consultas  geograficas.  Esta  es  una 
larga  y compleja  libreria,  consulta  mas  detalles  en:  ® http: / /geodjango.org/ 

• redirects:  un  framework  para  administrar  redirecciones.  Consulta  la  seccion 
titulada  “Redirects”  mas  adelante. 

• sessions:  el  framework  de  sesiones  de  Django.  Consulta  el  capitulo  12. 

• sitemaps:  un  framework  para  generara  archivos  de  mapas  de  sitio  XML. 
Consulta  el  capitulo  13. 

• sites:  un  framework  que  te  permite  operar  multiples  sitios  web  desde  la 
misma  base  de  datos,  y con  una  unica  instalacion  de  Django. 

• syndication:  un  framework  para  generar  documentos  de  sindicacion  (feeds), 
en  RSS  y en  Atom.  Consulta  el  capitulo  13. 

• webdesign:  Agregados  en  Django,  particularmente  utiles  en  el  diseno  Web 
mas  que  en  el  desarrollo.  Este  incluye  unicamente  una  etiqueta  {%  lorem  %}. 
que  permite  escribir  texto  en  las  plantillas. 

El  resto  de  este  capitulo  entra  en  los  detalles  de  cada  paquete  django.contrib  que 
no  ha  sido  cubierto  aun  en  este  libro. 

Sites 

El  sistema  sites  (sitios)  de  Django  es  un  framework  generico  que  te  permite  operar 
multiples  sitios  Web  desde  la  misma  base  de  datos,  y desde  el  mismo  proyecto  de 
Django.  Este  es  un  concepto  abstracto,  y puede  ser  dificil  de  entender,  asi  que 
comenzaremos  mostrando  algunos  escenarios  en  donde  seria  util  usarlo. 

Escenario  1:  rehuso  de  datos  en  multiples  sitios 

Como  explicamos  en  capitulos  anteriores,  los  sitios  LJWorld.com  y Lawrence.com, 
que  funcionan  gracias  a Django,  son  operados  por  la  misma  organization  de  prensa, 
el  diario  Lawrence  Journal-World  de  Lawrence,  Kansas.  LJWorld.com  se  enfoca  en 
noticias,  mientras  que  Lawrence.com  se  enfoca  en  el  entretenimiento  local.  Pero  a 
veces  los  editores  quieren  publicar  un  articulo  en  ambos  sitios. 
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La  forma  tonta  de  resolver  el  problema  serfa  usar  una  base  de  datos  para  cada 
sitio,  y pedirle  a los  productores  que  publiquen  la  misma  nota  dos  veces:  una  para 
LJWorld.com  y nuevamente  para  Lawrence.com.  Pero  esto  es  ineficiente  para  los 
productores  del  sitio,  y es  redundante  conservar  multiples  copias  de  la  misma  nota 
en  las  bases  de  datos. 

iUna  solution  mejor?  Que  ambos  sitios  usen  la  misma  base  de  datos  de  articulos,  y 
que  un  articulo  este  asociado  con  uno  o mas  sitios  por  una  relation  de  muchos-a- 
muchos.  El  framework  sites  de  Django,  proporciona  la  tabla  de  base  de  datos  que 
hace  que  los  articulos  se  puedan  relacionar  de  esta  forma.  Sirve  para  asociar  datos 
con  uno  o mas  “sitios”. 


Escenario  2:  alojamiento  del  nombre/dominio  de  tu  sitio  en  un  solo 

lugar 

Los  dos  sitios  LJWorld.com  y Lawrence.com,  tienen  la  funcionalidad  de  alertas  por 
correo  electronico,  que  les  permite  a los  lectores  registrarse  para  obtener 
notiflcaciones.  Es  bastante  basico:  un  lector  se  registra  en  un  formulario  web,  e 
inmediatamente  obtiene  un  correo  electronico  que  dice  “Gracias  por  su  suscripcion”. 

Serfa  ineficiente  y redundante  implementar  el  codigo  del  procesamiento  de 
registros  dos  veces,  asi  que  los  sitios  usan  el  mismo  codigo  detras  de  escena.  Pero  la 
noticia  “Gracias  por  su  suscripcion”  debe  ser  distinta  para  cada  sitio,  empleando 
objetos  Site,  podemos  abstraer  el  agradecimiento  para  usar  los  valores  del  nombre  y 
dominio  del  sitio,  variables  name  (ejemplo:  'LJWorld.com')  y domain  (ejemplo: 
'www.ljworld.com'). 

El  framework  sites  te  proporciona  un  lugar  para  que  puedas  almacenar  el  nombre 
(name)  y el  dominio  (domain)  de  cada  sitio  de  tu  proyecto,  lo  que  significa  que 
puedes  reutilizar  estos  valores  de  manera  generica. 

Como  usar  el  framework  sites 

Sites  mas  que  un  framework,  es  una  serie  de  convenciones.  Toda  la  cosa  se  basa  en 
dos  conceptos  simples: 

• El  modelo  Site,  que  se  halla  en  django.contrib. sites,  tiene  los  campos  domain 
y name. 

• La  option  de  configuracion  SITE_ID  especifica  el  ID  de  la  base  de  datos  del 
objeto  Site  asociado  con  este  archivo  de  configuracion  en  particular. 

La  manera  en  que  uses  estos  dos  conceptos  queda  a tu  criterio,  pero  Django  los 
usa  de  varios  modos  de  manera  automatica,  siguiendo  convenciones  simples. 

Para  instalar  la  aplicacion  sites,  sigue  estos  pasos: 

1.  Agrega  'django.contrib. sites'  a tu  INSTALLED_APPS. 

2.  Ejecuta  el  comando  python  manage. py  migrate  para  instalar  la  tabla 
django_site  en  tu  base  de  datos. 

3.  Agrega  uno  o mas  objetos  Site,  por  medio  del  sitio  de  administration  de 
Django,  o por  medio  de  la  API  de  Python.  Crea  un  objeto  Site  para  cada 
sitio /dominio  que  este  respaldado  por  este  proyecto  Django. 
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4.  Define  la  opcion  de  configuracion  SITE_ID  en  cada  uno  de  tus  archivos  de 
configuracion  {settings).  Este  valor  deberia  ser  el  ID  de  base  de  datos  del 
objeto  Site  para  el  sitio  respaldado  por  el  archivo  de  configuracion. 

Las  capacidades  del  framework  Sites 

Las  siguientes  secciones  describen  las  cosas  que  puedes  hacer  con  este  framework 


Rehusar  datos  en  multiples  sitios 

Para  rehusar  los  datos  en  multiples  sitios,  como  explicamos  en  el  primer  escenario, 
simplemente  debes  agregarle  un  campo  muchos-a-muchos,  ManyToManyField 
hacia  Site  en  tus  modelos. 

Por  ejemplo: 

from  django.db  import  models 

from  django.contrib. sites. models  import  Site 

class  Libro(models. Model): 

Dtitulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 

# ... 

sites  = models. ManyToManyField(Site) 


Esa  es  toda  la  infraestructura  necesaria  para  asociar  el  modelo  Libro  con  multiples 
sitios  en  tu  base  de  datos.  Con  eso  en  su  lugar,  puedes  rehusar  el  mismo  codigo  de 
vista  para  multiples  sitios.  Continuando  con  el  modelo  Libro  del  ejemplo,  aqui 
mostramos  como  luciria  una  vista  detalle_libro: 

from  django.conf  import  settings 
from  biblioteca.models  import  Libro 

def  detalle_libro(request,  libro  p k): 

try: 

libro  = Libro. objects. get(pk=libro_pk,  sites id=settings.SITE_ID) 

except  Libro. DoesNotExist: 
raise  Http404 

return  render_to_response(’biblioteca/detalles_libro.html’,  {’libro’:  libro}) 


Esta  funcion  de  vista  es  reusable  porque  comprueba  el  sitio  del  articulo 
dinamicamente,  segun  cual  sea  el  valor  de  la  opcion  SITE_ID. 

Por  ejemplo,  digamos  que  el  archivo  de  configuracion  de  LJWorld.com  tiene  un 
SITE_ID  asignado  a 1,  y que  el  de  Lawrence.com  lo  tiene  asignado  a 2.  Si  esta  vista  es 
llamada  cuando  el  archivo  de  configuracion  de  LJWorld.com  esta  activado,  entonces 
la  busqueda  de  articulos  se  limita  a aquellos  en  que  la  lista  de  sitios  incluye 
LJWorld.com. 

Asociacion  de  contenido  con  un  solo  sitio 


De  manera  similar,  puedes  asociar  un  modelo  con  el  modelo  Site  en  una  relation 
muchos-a-uno,  usando  ForeignKey. 
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Por  ejemplo,  si  un  articulo  solo  se  permite  en  un  sitio,  puedes  usar  un  modelo 
como  este: 

from  django.db  import  models 

from  django.contrib. sites. models  import  Site 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 

# ... 

sites  = models. ForeignKey(Site) 


Este  tiene  los  mismos  beneficios,  como  se  describe  en  la  ultima  section. 


Obtencion  del  sitio  actual  desde  las  vistas 

A un  nivel  mas  bajo,  puedes  usar  el  framework  sites  en  tus  vistas  de  Django  para 
hacer  cosas  particulars,  segun  el  sitio  en  el  cual  la  vista  sea  llamada.  Por  ejemplo: 

from  django.conf  import  settings 

def  mi_vista(request): 
if  settings. SITEJD  ==  3: 

# Haz  algo. 

else: 

# Haz  otra  cosa. 

Por  supuesto,  es  horrible  meter  el  ID  en  el  codigo  del  sitio  de  esa  manera.  Una 
forma  levemente  mas  limpia  de  lograr  lo  mismo,  es  comprobar  el  dominio  actual  del 
sitio: 

from  django.conf  import  settings 

from  django.contrib. sites. models  import  Site 

def  mi_vista(request): 

sitio_actual  = Site,  objects.  get(id=settings. SITEJD) 
if  sitio_actual. domain  ==  'foo.com': 

# Haz  algo. 

else: 

# Haz  otra  cosa. 

Este  fragmento  de  codigo  usado  para  obtener  el  objeto  Site  segun  el  valor  de 
settings. SITEJD  es  tan  usado,  que  el  manejador  de  modelos  de  Site  (Site. objects) 
tiene  un  metodo  get_current().  El  siguiente  ejemplo  es  equivalente  al  anterior: 

from  django.contrib. sites. models  import  Site 

def  mi_vista(request): 

sitio_actual  = Site. objects. get_current() 
if  sitio_actual. domain  ==  'foo.com': 

# Haz  algo, 
else: 

# Haz  otra  cosa. 
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Nota:  Observa  que  en  este  ultimo  ejemplo,  no  hay  necesidad  de  importar 
django.conf.settings. 


Obtencion  del  dominio  actual  para  ser  mostrado 


Una  forma  DRY  (acronimo  del  ingles  Don’t  Repeat  Yourself,  “no  te  repitas”)  de 
guardar  el  nombre  del  sitio  y del  dominio,  como  explicamos  en  “Escenario  2: 
alojamiento  del  nombre  /dominio  de  tu  sitio  en  un  solo  lugar”,  se  logra  simplemente 
haciendo  referencia  a name  y a domain  del  objeto  Site  actual.  Por  ejemplo: 

from  django.contrib. sites. models  import  Site 
from  django. core. mail  import  send_mail 

def  registrar_para_boletines(request): 

# Verifica  los  valores  del  formulario,  etc.,  y suscribe  al  usuario. 

# ... 

sitio_actual  = Site. objects. get_current() 

send_mail(’Gracias  por  suscribirse  a %s  alertas’  % sitio_actual.name, 

’Gracias  por  suscribirse.  Se  lo  agradecemos.\n\n-EI  %s  equipo.’  % 
sitio_actual.name,  ’editor@%s’  % sitio_actual. domain, 

[user_email]) 

# ... 

Continuando  con  nuestro  ejemplo  de  LJWorld.com  y Lawrence.com,  en 
Lawrence.com  el  correo  electronico  tiene  como  sujeto  la  linea  “Gracias  por 
suscribirse  a las  alertas  de  lawrence.com”.  En  LJWorld.com,  en  cambio,  el  sujeto  es 
“Gracias  por  suscribirse  a las  alertas  de  LJWorld.com”.  Este  comportamiento 
especifico  para  cada  sitio,  tambien  se  aplica  al  cuerpo  del  correo  electronico. 

Una  forma  aun  mas  flexible  (aunque  un  poco  mas  pesada)  de  hacer  lo  mismo,  es 
usando  el  sistema  de  plantillas  de  Django.  Asumiendo  que  Lawrence.com  y 
LJWorld.com  tienen  distintos  directorios  de  plantillas  (TEMPIATE_DIRS),  puedes 
simplemente  delegarlo  al  sistema  de  plantillas  asi: 

from  django. core. mail  import  send_mail 
from  django. template  import  loader,  Context 

def  registrar_para_boletines(request): 

# Verifica  los  valores  del  formulario,  etc.,  y suscribe  al  usuario. 

# ... 

asunto  = loader.  get_template('alertas/asunto.txt’).render(Context({})) 
mensaje  = loader.  get_template(’alertas/mensaje.txt’).render(Context({})) 
send_mail(asunto,  mensaje,  ’do-not-reply@example.com’,  [user_email]) 

# ... 

En  este  caso,  debes  crear  las  plantillas  asunto.txt  y mensaje.txt  en  ambos 
directorios  de  plantillas,  el  de  LJWorld.com  y el  de  Lawrence.com  . Como 
mencionamos  anteriormente,  eso  te  da  mas  flexibilidad,  pero  tambien  es  mas 
complejo. 
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Una  buena  idea  es  explotar  los  objetos  Site  lo  mas  posible,  para  que  no  haya 
complejidad  y redundancia  innecesaria. 

Obtencion  del  dominio  actual  para  las  URLs  completas 

La  convention  de  Django  de  usar  get_absolute_url()  para  obtener  las  URLs  de  los 
objetos  sin  el  dominio,  esta  muy  bien.  Pero  en  algunos  casos  puedes  querer  mostrar 
la  URL  completa  - con  http://  y el  dominio,  y todo  - para  un  objeto.  Para  hacerlo, 
puedes  usar  el  framework  sites.  Este  es  un  ejemplo: 

»>  from  django.contrib. sites. models  import  Site 
»>  from  biblioteca.models  import  Libro 
»>  obj  = Libro. objects. get(  =3) 

»>  obj.get_absolute_url() 

’/d  etal  I e/I  i b ro/3/’ 

»>  Site. objects. get_current(). domain 

’localhost:9000’ 

»>  ’http://%s%s’  % (Site. objects. get_current(). domain,  obj.get_absolute_url()) 

’http://localhost:9000/detalle/libro/3/’ 


El  manejador  CurrentSiteManager 

Si  el  modelo  Site  juegan  roles  importantes  en  tu  aplicacion,  considera  el  uso  del  util 
manejador  llamado:  CurrentSiteManager  en  tu  modelo  (o  modelos).  Es  un 
administrador  de  modelos  (consulta  el  Apendice  B)  que  filtra  automaticamente  sus 
consultas  para  incluir  solo  los  objetos  asociados  al  Site  actual. 

Usa  CurrentSiteManager  agregandolo  a tu  modelo  explicitamente.  Por  ejemplo: 

from  django.db  import  models 

from  django.contrib. sites. models  import  Site 

from  django.contrib. sites. managers  import  CurrentSiteManager 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 

# Agregamos  una  relacion  foranea  a "Sites" 

sites  = models. ForeignKey(Site) 

# El  manejador  por  defecto. 

objects  = models.  ManagerQ 

# Agregamos  el  manejador  para  "Sites" 

mi_sitio  = CurrentSiteManagerQ 


Con  este  modelo,  Libro. objects. all()  retorna  todos  los  objetos  Libro  de  la  base  de 
datos,  pero  Libro. mi_sitio.all()  retorna  solo  los  objetos  Libro  asociados  con  el  sitio 
actual,  de  acuerdo  a la  option  de  configuration  SITE_ID. 

En  otras  palabras,  estas  dos  sentencias  son  equivalentes: 

Libro. objects. filter(site=settings.SITE_l  D) 

Libro. mi_sitio.all() 

jComo  supo  CurrentSiteManager  cual  campo  de  Libro  era  el  Site?  Por  defecto 
busca  un  campo  llamado  site.  Si  tu  modelo  tiene  un  campo  ForeignKey  o un  campo 
ManyToManyField  llamado  de  otra  forma  que  site,  debes  pasarlo  explicitamente 
como  el  parametro  para  CurrentSiteManager. 
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El  modelo  a continuation,  tiene  un  campo  llamado  publicado_en,  como  lo 
demuestra  el  siguiente  ejemplo: 

from  django.db  import  models 

from  django.contrib. sites. models  import  Site 

from  django.contrib. sites. managers  import  CurrentSiteManager 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 
autores  = models. ManyToManyField(Autor) 

# Agrega  una  relacion  foranea  usando  otro  nombre  en  lugar  de  "sites" 

publicado_en  = models. ForeignKey(Site) 

# El  manejador  por  defecto. 

objects  = models.  Manager() 

# Agrega  al  manejador  el  nombre  del  campo:  "Sites" 

mi_sitio  = CurrentSiteManager(’publicado_en’) 


Si  intentas  usar  CurrentSiteManager  y pasarle  un  nombre  de  campo  que  no  existe, 
Django  lanzara  un  error  del  tipo:  ValueError. 


Nota:  Probablemente  querras  tener  un  Manager  normal  (no  especifico  al  sitio)  en 
tu  modelo,  incluso  si  usas  CurrentSiteManager.  Como  se  explica  en  el  Apendice  B,  si 
defines  un  manager  manualmente,  Django  no  creara  automaticamente  el  manager 
objects  = models. Manager  (). 

Ademas,  algunas  partes  de  Django  - el  sitio  de  administration  y las  vistas 
genericas  - usan  el  manager  que  haya  sido  definido  primero  en  el  modelo.  Asi  que  si 
quieres  que  el  sitio  de  administration  tenga  acceso  a todos  los  objetos  (no  solo  a los 
especificos  al  sitio  actual),  pon  un  objects  = models. Managed)  en  tu  modelo,  antes 
de  definir  CurrentSiteManager. 


Si  utilizas  a menudo  esta  configuration,  en  lugar  de  hacer  esto  en  tus  vistas: 

from  django.contrib. sites. models  import  Site 

def  mi_vista(request): 

site  = Site. objects. get_current() 


Existe  una  manera  simple  de  evitar  repeticiones.  Usando  Middleware,  solo  agrega 
django.contrib. sites. middleware. CurrentSiteMiddleware  a la  variable 
MIDDLEWARE_CLASSES.  El  middleware  se  encarga  de  configurar  estos  atributos  en 
cada  petition  de  un  objeto,  por  lo  que  puedes  usar  request.site  para  obtener  el  sitio 
actual. 


Como  utilizar  Django  el  framework  Sites 

Si  bien  no  es  necesario  que  uses  el  framework  sites,  es  extremadamente 
recomendado,  porque  Django  toma  ventaja  de  ello  en  algunos  lugares.  Incluso  si  tu 
instalacion  de  Django  esta  alimentando  a un  solo  sitio,  deberfas  tomarte  unos 
segundos  para  crear  el  objeto  site  con  tu  domain  y name,  y apuntar  su  ID  en  tu 
option  de  configuration  SITE_ID. 
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Este  es  el  uso  que  hace  Django  del  framework  sites-. 

• En  el  framework  redirects  (consulta  la  section  “Redirects”  mas  adelante) , cada 
objeto  redirected  asociado  con  un  sitio  en  particular.  Cuando  Django  busca 
un  redirect,  toma  en  cuenta  el  SITE_ID  actual. 

• En  el  framework  flatpages  (consulta  la  section  “Flatpages”  mas  adelante), 
cada  pagina  es  asociada  con  un  sitio  en  particular.  Cuando  una  pagina  es 
creada,  tu  especificas  su  site,  y el  middleware  de  flatpage  chequea  el  SITE_ID 
actual  cuando  se  traen  paginas  para  ser  mostradas. 

• En  el  framework  syndication  (consulta  el  capitulo  13.),  las  plantillas  para  title  y 
description  tienen  acceso  automatico  a la  variable  {{  site  }},  que  es  el  objeto 
Site  que  representa  al  sitio  actual.  Ademas,  la  conexion  para  proporcionar  las 
URLs  de  los  elementos  usan  el  domain  desde  el  objeto  Site  actual  si  no 
especificas  un  nombre  de  dominio. 

• En  el  framework  authentication  (consulta  el  capitulo  14.),  la  vista 
django.contrib.auth.views.login  le  pasa  el  nombre  del  Site  actual  a la  plantilla 
como  {{ site_name }}. 


Flatpages 

A menudo  tendras  una  aplicacion  Web  impulsada  por  una  bases  de  datos  ya 
funcionando,  pero  necesitaras  agregar  un  par  de  paginas  estaticas,  tales  como  una 
pagina  Acerca  de  o una  pagina  de  Politica  de  Privacidad.  Seria  posible  usar  un 
servidor  Web  estandar  como  por  ejemplo  Apache  para  servir  esos  archivos  como 
archivos  E1TML  pianos,  pero  eso  introduce  un  nivel  extra  de  complejidad  en  tu 
aplicacion,  porque  entonces  tienes  que  preocuparte  de  la  configuration  de  Apache, 
tienes  que  preparar  el  acceso  para  que  tu  equipo  pueda  editar  esos  archivos,  y no 
puedes  sacar  provecho  del  sistema  de  plantillas  de  Django  para  darle  estilo  a las 
paginas. 

La  solution  a este  problema  es  la  aplicacion  flatpages  de  Django,  la  cual  reside  en 
el  paquete  django.contrib.flatpages.  Esta  aplicacion  te  permite  manejar  esas  paginas 
aisladas  mediante  el  sitio  de  administration  de  Django,  y te  permite  especificar 
plantillas  para  las  mismas  usando  el  sistema  de  plantillas  de  Django.  Detras  de 
escena  usa  modelos  Django,  lo  que  significa  que  almacena  las  paginas  en  una  base  de 
datos,  de  la  misma  manera  que  el  resto  de  tus  datos,  y puedes  acceder  a las  flatpages 
con  la  API  de  bases  de  datos  estandar  de  Django. 

Las  flatpages  son  identificadas  por  su  URL  y su  sitio.  Cuando  creas  una  flatpage, 
especificas  con  cual  URL  esta  asociada,  junto  con  en  cual(es)  sitio (s)  esta  (para  mas 
information  acerca  de  sitios,  consulta  la  section  “Sites”). 

Usar  Flatpages 

Para  instalar  la  aplicacion  flatpages,  sigue  estos  pasos: 

1.  Agrega  'django.contrib.flatpages'  a tu  INSTALLED_APPS. 
django.contrib.flatpages  depende  de  django.contrib. sites,  asi  que  asegurate  de 
que  ambos  paquetes  se  encuentren  en  INSTALLED_APPS. 

2.  Agrega  'django.contrib. flatpages. middleware. FlatpageFallbackMiddleware'  a 
tu  variable  de  configuration  MIDDLEWARE_CLASSES. 
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3.  Ejecuta  el  comando  python  manage. py  migrate  para  instalar  las  dos  tablas 
necesarias  en  tu  base  de  datos. 

La  aplicacion  flatpages  crea  dos  tablas  en  tu  base  de  datos:  django_flatpage  y 
django_flatpage_sites.  django_flatpage  simplemente  mantiene  una  correspondencia 
entre  URLs  y titulos  mas  contenidos  de  texto.  django_flatpage_sites  es  una  tabla 
muchos  a muchos  que  asocia  una  flatpage  con  uno  o mas  sitios. 

La  aplicacion  incluye  un  unico  modelo  FlatPage,  definido  en 
django/contrib/flatpages/models.py.  El  mismo  se  ve  asi: 

from  django.db  import  models 

from  django.contrib. sites. models  import  Site 

class  FlatPage(models. Model): 

url  = models.  CharField(maxlength=100) 

title  = models.  CharField(maxlength=200) 

content  = models. TextField() 

enable_comments  = models. BooleanField() 

template_name  = models. CharField(maxlength=70,  blank=  ) 

registration_required  = models.  BooleanField() 

sites  = models. ManyToManyField(Site) 


Examinemos  cada  uno  de  los  campos: 

• url:  La  URL  donde  reside  esta  flatpage,  excluyendo  el  nombre  del  dominio 
pero  incluyendo  labarra  (/)  inicial  (por  ej.  /about/contact/). 

• title:  El  titulo  de  la  flatpage.  El  framework  no  usa  esto  para  nada  en  especial. 
Es  tu  responsabilidad  visualizarlo  en  tu  plantilla. 

• content:  El  contenido  de  la  flatpage  (por  ej.  el  HTML  de  la  pagina).  El 
framework  no  usa  esto  para  nada  en  especial.  Es  tu  responsabilidad 
visualizarlo  en  tu  plantilla. 

• enable_comments:  Indica  si  deben  activarse  los  comentarios  e esta  flatpage. 
El  framework  no  usa  esto  para  nada  en  especial.  Puedes  comprobar  este  valor 
en  tu  plantilla  y mostrar  un  formulario  de  comentario  si  es  necesario. 

• template_name:  El  nombre  de  la  plantilla  a usarse  para  renderizar  esta 
flatpage.  Es  opcional;  si  no  se  indica  o si  esta  plantilla  no  existe,  el  framework 
usara  la  plantilla  flatpages/ default.html. 

• registration_required:  Indica  si  se  requerira  registro  para  ver  esta  flatpage. 
Esto  se  integra  con  el  framework  de  autenticacion/usuarios  de  Django,  el  cual 
se  trata  en  el  capitulo  12. 

• sites:  Los  sitios  en  los  cuales  reside  esta  flatpage.  Esto  se  integra  con  el 
framework  sites  de  Django,  el  cual  se  trata  en  la  seccion  “Sites”  en  este 
capitulo. 

Puedes  crear  flatpages  ya  sea  a traves  de  la  interfaz  de  administration  de  Django  o 
a traves  de  la  API  de  base  de  datos  de  Django.  Para  mas  information,  examina  la 
seccion  “Agregando,  modificando  y eliminando  flatpaged' . 
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Una  vez  que  has  creado  flatpages,  FlatpageFallbackMiddleware  se  encarga  de  todo 
el  trabajo.  Cada  vez  que  cualquier  aplicacion  Django  lanza  un  error,  este  middleware 
verifica  como  ultimo  recurso  la  base  de  datos  de  flatpages  en  busqueda  de  la  URL  que 
se  ha  requerido. 

Especificamente  busca  una  flatpage  con  la  URL  en  cuestion  y con  un  identificador 
de  sitio  que  coincida  con  la  variable  de  configuration  SITE_ID. 

Si  encuentra  una  coincidencia,  carga  la  plantilla  de  la  flatpage,  o 
flatpages /default.html  si  la  flatpage  no  ha  especificado  una  plantilla  personalizada. 
Le  pasa  a dicha  plantilla  una  unica  variable  de  contexto:  flatpage,  la  cual  es  el  objeto 
flatpage.  Usa  RequestContext  para  renderizar  la  plantilla. 

Si  FlatpageFallbackMiddleware  no  encuentra  una  coincidencia,  el  proceso  de  la 
petition  continua  normalmente. 


Nota:  Este  middleware  solo  se  activa  para  errores  404  (pagina  no  encontrada)  - 
no  para  errores  500  (error  en  servidor)  u otras  respuestas  de  error.  Nota  tambien  que 
el  orden  de  MIDDLEWARE_CLASSES  es  relevante.  Generalmente,  puedes  colocar  el 
FlatpageFallbackMiddleware  cerca  o en  el  final  de  la  lista,  debido  a que  se  trata  de 
una  option  de  ultimo  recurso. 


Agregar,  modificar  y eliminar  flatpages 

Puedes  agregar,  cambiary/o  eliminar  paginas  estaticas  o flatpages  de  dos  maneras: 

1 . A traves  de  la  interfaz  de  administration 

Si  has  activado  la  interfaz  automatica  de  administration  de  Django,  deberias 
ver  una  section  “Flatpages”  en  la  pagina  de  indice  de  la  aplicacion  admin. 
Edita  las  flatpages  como  lo  harias  con  cualquier  otro  objeto  en  el  sistema. 

2.  A traves  de  de  la  API  Python 

Como  ya  se  describio,  las  flatpages  se  representan  mediante  un  modelo 
Django  estandar  que  reside  en  django/contrib/flatpages/models.py.  Por  lo 
tanto  puede  acceder  a objetos  flatpage  mediante  la  API  de  base  de  datos 
Django,  por  ejemplo: 

»>  from  django.contrib. flatpages. models  import  FlatPage 
»>  from  django.contrib. sites. models  import  Site 
»>  fp  = FlatPage( 
url=7acerca/’, 

...  title- Acerca  de  ’, 

...  content=’<p>Acerca  de  este  sitio. ,.</p>’, 

enable_comments=  alst , 

...  template_name=”, 

registration_required=  alse, 

...) 

»>  fp.saveQ 

»>  fp. sites. add(Site. objects. get(  =1)) 

»>  FlatPage. objects. get(url=7acerca/’) 

<FlatPage:  /acerca/  - Acerca  de> 
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Usar  plantillas  de  flatpages 

Por  omision,  las  flatpages  son  renderizadas  via  la  plantilla  flatpages/default.html, 
pero  puedes  cambiar  eso  para  cualquier  flatpage  con  el  campo  template_name  en  el 
objeto  FlatPage. 

Es  tu  responsabilidad  el  crear  la  plantilla  flatpages/default.html.  En  tu  directorio 
de  plantillas,  crea  un  directorio  flatpages  que  contenga  un  archivo  default.html. 

A las  plantillas  de  flatpages  se  les  pasa  una  unica  variable  de  contexto:  flatpage,  la 
cual  es  el  objeto  flatpage. 

Este  es  un  ejemplo  de  una  plantilla  flatpages/default.html: 

<!DOCTYPE  HTML  PUBLIC  "-//W3C//DTD  HTML  4.0  Transitional//EN" 
"http://www.w3.org/TR/REC-html40/loose.dtd"> 

<html> 

<head> 

<title>{{  flatpage. title  }}</title> 

</head> 

<body> 

{{ flatpage. content }} 

</body> 

</html> 


Redirects 


El  framework  redirects  de  Django  te  permite  administrar  las  redirecciones  con 
facilidad  almacenandolos  en  una  base  de  datos  y tratandolos  como  cualquier  otro 
objeto  modelo  de  Django.  Por  ejemplo  puedes  usar  el  framework  redirects  para 
indicarle  a Django  “Redirecciona  cualquier  petition  de  /musica/  a 
/seccion/artista/musica/.”.  Esto  es  util  cuando  necesitas  cambiar  las  cosas  de  lugar 
en  tu  sitio;  los  desarrolladores  Web  deberian  hacer  lo  que  este  en  sus  manos  para 
evitar  los  enlaces  rotos. 

Usando  el  framework  redirects 

Para  instalar  la  aplicacion  redirects,  sigue  estos  pasos: 

■ Agrega  'django.contrib.redirects'  a tu  INSTALLED_APPS. 

■ Agrega  'django.contrib. redirects. middleware. RedirectFallbackMiddleware'  a 
tu  variable  de  configuration  MIDDLEWARE_CLASSES. 

■ Ejecuta  el  comando  python  manage. py  migrate  para  instalar  la  unica  tabla 
necesaria  a tu  base  de  datos. 

manage. py  migrate  crea  una  tabla  django_redirect  en  tu  base  de  datos.  Esta  se 
trata  sencillamente  de  una  tabla  de  busqueda  con  campos  site_id,  old_path  y 
new_path. 

Puedes  crear  redirecciones  tanto  a traves  de  la  interfaz  de  administration  como  a 
traves  de  la  API  de  base  de  datos  de  Django.  Para  mas  information  puedes  leer  la 
section  “Agregar,  modificar  y eliminar  redirecciones”. 


338  CAPITULO  16  EL  PAQUETE  DJANGO. CONTRIB 


Una  vez  que  has  creado  redirecciones,  la  clase  RedirectFallbackMiddleware  se 
encarga  de  todo  el  trabajo.  Cada  vez  que  cualquier  aplicacion  Django  lanza  un  error 
404,  este  middleware  verifica  como  ultimo  recurso  la  base  de  datos  de  redirects  en 
busqueda  de  la  URL  que  se  ha  requerido.  Especificamente  busca  un  redirect  con  el 
old_path  provisto  y con  un  identificador  de  sitio  que  coincida  con  la  variable  de 
configuration  SITE_ID.  (para  mas  information  acerca  de  SITE_ID  y el  framework 
sites,  consulta  la  section  “Sites”). 

Luego  entonces  realiza  los  siguientes  pasos: 

■ Si  encuentra  una  coincidencia  y new_path  no  esta  vatio,  redirecciona  la 
petition  a new_path. 

■ Si  encuentra  una  coincidencia  y new_path  esta  vacio,  envia  una  cabecera 
HTTP  410  (“Ausente”)  y una  respuesta  vatia  (sin  contenido). 

■ Si  no  encuentra  una  coincidencia,  el  procesamiento  de  la  petition  continua 
normalmente. 

El  middleware  solo  se  activa  ante  errores  404  - no  en  errores  500  o respuestas  con 
otros  codigos  de  estado. 


Nota:  que  el  orden  de  MIDDLEWARE_CLASSES  es  relevante.  Generalmente 
puedes  colocar  RedirectFallbackMiddleware  cerca  del  final  de  la  lista,  debido  a que 
se  trata  de  una  option  de  ultimo  recurso. 


Si  usas  los  middlewares  redirect  y flatpages,  analiza  cual  de  los  dos  (redirect  o 
flatpages)  desearias  sea  ejecutado  primero.  Sugerimos  configurar  flatpages  antes  que 
redirects  (o  sea  colocar  el  middleware  flatpages  antes  que  el  middleware  redirects) 
pero  tu  podrias  decidir  lo  contrario. 

Agregar,  modificar  y eliminar  redirecciones 


Puedes  agregar,  modificar  y eliminar  redirecciones  de  dos  maneras: 

1.  A traves  de  la  interfaz  de  administration 

Si  has  activado  la  interfaz  automatica  de  administration  de  Django,  deberias 
ver  una  section  “Redirects”  en  la  pagina  de  indice  de  la  aplicacion  admin. 
Edita  las  redirecciones  como  lo  harias  con  cualquier  otro  objeto  en  el  sistema. 

2.  A traves  de  la  API  Python 

Las  redirecciones  se  representan  mediante  un  modelo  estandar  Django  que 
reside  en  django/contrib /redirects / models. py.  Por  lo  tanto  puedes  acceder  a 
los  objetos  redirect  via  la  API  de  base  de  datos  de  Django,  por  ejemplo: 

»>  from  django.contrib. redirects. models  import  Redirect 
»>  from  django.contrib. sites. models  import  Site 
»>  red  = Redirect( 

...  site=Site. objects. get(  =1), 

...  old_path=7musica/’, 

...  new_path=7seccion/artista/musica/\ 
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...) 

»>  red.saveQ 

»>  Redirect.objects.get(old_path=7musica/’) 

<Redirect:  /music/  — > /secccion/artista/musica/> 


Proteccion  contra  CSRF 


El  paquete  django.contrib.csrf  provee  proteccion  contra  Cross-site  request  forgery 
(CSRF)  (falsification  de  peticiones  inter-sitio). 

CSRF,  tambien  conocido  como  " session  riding”  (montado  de  sesiones)  es  un 
exploit  de  seguridad  en  sitios  Web.  Se  presenta  cuando  un  sitio  Web  malicioso  induce 
a un  usuario  a cargar  sin  saberlo  una  URL  desde  un  sitio  al  cual  dicho  usuario  ya  se  ha 
autenticado,  por  lo  tanto  saca  ventaja  de  su  estado  autenticado.  Inicialmente  esto 
puede  ser  un  poco  dificil  de  entender  asi  que  en  esta  section  recorreremos  un  par  de 
ejemplos. 

Un  ejemplo  simple  de  CSRF 

Supongamos  que  posees  una  cuenta  de  correo  electronico  en  example.com.  Este  sitio 
proveedor  de  correo  tiene  un  boton  Log  Out  que  apunta  a la  URL 
example.com/logout  - esta  es,  la  unica  action  que  necesitas  realizar  para 
desconectarte  ( logout ) esvisitarlapaginaexample.com/logout. 

Un  sitio  malicioso  puede  obligarte  a visitar  la  URL  example.com/logout 
incluyendo  esa  URL  como  un  <iframe>  oculto  en  su  propia  pagina  maliciosa.  De 
manera  que  si  estas  conectado  0 logged  in)  a tu  cuenta  de  correo  del  sitio 
example.com  y visitas  la  pagina  maliciosa,  el  hecho  de  visitar  la  misma  te 
desconectara  de  example.com. 

Claramente,  ser  desconectado  de  un  sitio  de  correo  contra  tu  voluntad  no  es  un 
incidente  de  seguridad  aterrorizante,  pero  este  tipo  de  exploit  puede  sucederle  a 
cualquier  sitio  que  “confia”  en  sus  usuarios,  tales  como  un  sitio  de  un  banco  o un 
sitio  de  comercio  electronico. 

Un  ejemplo  mas  complejo  de  CSRF 

En  el  ejemplo  anterior,  el  sitio  example.com  tenia  parte  de  la  culpa  debido  a que 
permitia  que  se  pudiera  solicitar  un  cambio  de  estado  (la  desconexion  del  sitio) 
mediante  el  metodo  HTTP  GET. 

Es  una  practica  mucho  mejor  el  requerir  el  uso  de  un  POST  HTTP  para  cada 
petition  que  cambie  el  estado  en  el  servidor.  Pero  aun  los  sitios  Web  que  requieren  el 
uso  de  POST  para  acciones  que  signifiquen  cambios  de  estado  son  vulnerables  a 
CSRF. 

Supongamos  que  example.com  ha  mejorado  su  funcionalidad  de  desconexion  de 
manera  que  “Log  Out”  es  ahora  un  boton  de  un  <form>  que  es  enviado  via  un  POST  a 
la  URL  example.com/logout.  Adicionalmente,  el  <form>  de  desconexion  incluye  un 
campo  oculto: 

<input  type=" hidden"  name=" confirm"  value="true"  /> 

Esto  asegura  que  un  simple  POST  a la  URL  example.com/logout  no  desconectara  a 
un  usuario;  para  que  los  usuarios  puedan  desconectarse,  deberan  enviar  una  petition 
a example.com/logout  usando  POST  / enviar  la  variable  POST  confirm  con  el  valor 
'true'. 
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Bueno,  aun  con  dichas  medidas  extra  de  seguridad,  este  esquema  tambien  puede 
ser  atacado  mediante  CSRF  - la  pagina  maliciosa  solo  necesita  hacer  un  poquito  mas 
de  trabajo.  Los  atacantes  pueden  crear  un  formulario  completo  que  envie  su  petition 
a tu  sitio,  ocultar  el  mismo  en  un  <iframe>  invisible  y luego  usar  JavaScript  para 
enviar  dicho  formulario  en  forma  automatica. 

Previniendo  CSRF 

Entonces,  jComo  puede  tu  sitio  defenderse  de  este  exploit?.  El  primer  paso  es 
asegurarse  que  todas  las  peticiones  GET  no  posean  efectos  colaterales.  De  esa  forma, 
si  un  sitio  malicioso  incluye  una  de  tus  paginas  como  un  <iframe>,  esto  no  tendra  un 
efecto  negativo. 

Esto  nos  deja  con  las  peticiones  POST.  El  segundo  paso  es  dotar  a cada  <form>  que 
se  enviara  via  POST  un  campo  oculto  cuyo  valor  sea  secreto  y sea  generado  en  base  al 
identilicador  de  sesion  del  usuario.  Entonces  luego,  cuando  se  este  realizando  el 
procesamiento  del  formulario  en  el  servidor,  comprobar  dicho  campo  secreto  y 
generar  un  error  si  dicha  comprobacion  no  es  exitosa. 

Esto  es  precisamente  lo  que  hace  la  capa  de  prevention  de  CSRF  de  Django,  tal 
como  se  explica  en  la  siguiente  section. 

Usar  el  middleware  CSRF 

El  paquete  django.contrib.csrf  contiene  solo  un  modulo:  middleware.py.  Este  modulo 
contiene  una  clase  middleware  Django:  CsrfMiddleware  la  cual  implementa  la 
protection  contra  CSRF,  por  defecto. 

Para  activar  esta  protection  en  tiempos  de  ejecucucion,  solo  agrega 
'django.contrib.csrf.middleware.CsrfMiddleware'  a la  variable  de  configuration 
MIDDLEWARE_CLASSES  en  tu  archivo  de  configuration.  Este  middleware  necesita 
procesar  la  respuesta  despues  de  SessionMiddleware,  asi  que  CsrfMiddleware  debe 
aparecer  antes  que  SessionMiddleware  en  la  lista  (esto  es  debido  que  el  middleware 
de  respuesta  es  procesado  de  atras  hacia  adelante).  Por  otra  parte,  debe  procesar  la 
respuesta  antes  que  la  misma  sea  comprimida  o alterada  de  alguna  otra  forma,  de 
manera  que  CsrfMiddleware  debe  aparecer  despues  de  GZipMiddleware.  Tina  vez 
que  has  agregado  eso  a tu  MIDDLEWARE_CLASSES  ya  estas  listo  para  usarlo,  tanto 
en  plantillas  como  en  vistas. 

En  cualquier  plantilla  que  use  un  formulario  POST,  usa  la  etiqueta  csrf_token 
dentro  de  los  elementos  <form>  si  el  formulario  es  para  una  URL  interna.  Por 
ejemplo: 

<form  action-'."  method="post">{%  csrf_token  %} 

Esto  no  se  debe  de  hacer  en  formularios  POST  que  apunten  a URLs  externas,  ya 
que  esto  causaria  que  el  CSRF  sea  escapado,  conduciendonos  a problemas  de 
vulnerabilidad. 

En  las  vistas,  solo  asegurate  de  que  el  procesador  de  contexto: 
django.core.context_processors.csrf  sea  usado.  Usualmente  puedes  hacerlo  de  dos 
formas: 

1.  Usando  RequestContext,  el  cual  siempre  usa 

django.core.context_processors.csrf  (no  importando  la  configuration  de 
TEMPLATE_CONTEXT_PROCESSORS).  Si  estas  usando  una  vista  generica  o 
una  aplicacion  del  paquete  contrib,  estas  a salvo,  ya  que  estas  aplicaciones  ya 
incluyen  RequestContext  por  defecto. 
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2.  Manualmente  importa  y usa  el  procesador  generado  por  el  token  CSRF  y 
agregalo  en  el  contexto  de  la  plantilla,  asi: 

from  django.core.context_processors  import  csrf 
from  django. shortcuts  import  render_to_response 

def  mi_vista(request): 

c = {} 

c.update(csrf(request)) 

# ...  el  codigo  de  la  vista  aqul. 

return  render_to_response("mi  plantilla. html",  c) 

Finalmente  puedes  usar  un  decorador  que  envuelva  tu  vista  y que  tome  en  cuenta 
estos  pasos  por  ti. 

from  django. views. decorators. csrf  import  csrf_protect 
from  django. shortcuts  import  render 

@csrf_protect 
def  mi_vista(request): 

c = {} 

# ... 

return  render(request,  "a_template.htmr’,  c) 


® Advertencia:  El  uso  del  decorador  por  si  mismo  no  es  muy  recomendable,  ya  que 
si  olvidas  utilizarlo,  tendras  un  gran  agujero  de  seguridad. 


En  el  caso  en  el  que  estes  interesado,  asi  es  como  trabaja  CsrfMiddleware. 
Realizando  estas  dos  cosas: 

1.  Modifica  las  respuestas  salientes  a peticiones  agregando  un  campo  de 
formulario  oculto  a todos  los  formularios  POST,  con  el  nombre 
csrfmiddlewaretoken  y un  valor  que  es  un  hash  del  identificador  de  sesion 
mas  una  clave  secreta.  El  middleware  no  modifica  la  respuesta  si  no  existe  un 
identificador  de  sesion,  de  manera  que  el  costo  en  rendimiento  es 
despreciable  para  peticiones  que  no  usan  sesiones. 

2.  Para  todas  las  peticiones  POST  que  porten  la  cookie  de  sesion,  comprueba 
que  csrfmiddlewaretoken  este  presente  y tenga  un  valor  correcto.  Si  no 
cumple  estas  condiciones,  el  usuario  recibira  un  error  F1TTP  403.  El  contenido 
de  la  pagina  de  error  es  el  mensaje  “Cross  Site  Request  Forgery  detected. 
Request  aborted.” 

Esto  asegura  que  solamente  se  puedan  usar  formularios  que  se  hayan  originado  en 
tu  sitio  Web  para  enviar  datos  via  POST  al  mismo. 

Este  middleware  deliberadamente  trabaja  solamente  sobre  peticiones  F1TTP  POST 
(y  sus  correspondientes  formularios  POST).  Como  ya  hemos  explicado,  las  peticiones 
GET  nunca  deberian  tener  efectos  colaterales;  es  tu  responsabilidad  asegurar  eso. 

Las  peticiones  POST  que  no  esten  acompanadas  de  una  cookie  de  sesion  no  son 
protegidas  simplemente  porque  no  tiene  sentido  protegerlas,  un  sitio  Web  malicioso 
podria  de  todas  formas  generar  ese  tipo  de  peticiones. 
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Para  evitar  alterar  peticiones  no  HTML,  el  middleware  revisa  la  cabecera  Content- 
Type  de  la  respuesta  antes  de  modificarla.  Solo  modifica  las  paginas  que  son  servidas 
como  text/html  o application /xml+xhtml. 


Limitaciones  del  middleware  CSRF 

CsrfMiddleware  necesita  el  framework  de  sesiones  de  Django  para  poder  funcionar. 
(Revisa  el  capitulo  14 para  obtener  mas  informacion  sobre  sesiones).  Si  estas  usando 
un  framework  de  sesiones  o autenticacion  personalizado  que  maneja  en  forma 
manual  las  cookies  de  sesion,  este  middleware  no  te  sera  de  ayuda. 

Si  tu  aplicacion  crea  paginas  HTML  y formularios  con  algun  metodo  inusual  (por 
ej.  si  envia  fragmentos  de  HTML  en  sentencias  JavaScript  document. write),  podrias 
estar  salteandote  el  filtro  que  agrega  el  campo  oculto  al  formulario.  De  presentarse 
esta  situation,  el  envio  del  formulario  fallara  siempre.  (Esto  sucede  porque 
CsrfMiddleware  usa  una  expresion  regular  para  agregar  el  campo 
csrfmiddlewaretoken  a tu  HTML  antes  de  que  la  pagina  sea  enviada  al  cliente,  y la 
expresion  regular  a veces  no  puede  manejar  codigo  HTML  muy  extravagante).  Si 
sospechas  que  esto  podria  estar  sucediendo,  solo  examina  el  codigo  en  tu  navegador 
Web  para  ver  si  es  que  csrfmiddlewaretoken  ha  sido  insertado  en  tu  <form>. 

Para  mas  informacion  y ejemplos  sobre  CSRF,  visita 
(f)  http://en.wikipedia.org/wiki/CSRF. 

Humanizando  Datos 


El  paquete  contrib. humanize  es  una  aplicacion  que  aloja  un  conjunto  de  flltros  de 
plantilla  utiles  a la  hora  de  agregar  un  “toque  humano”  a los  datos.  Para  activar  esos 
filtros,  agrega  'django.contrib.humanize'  a tu  variable  de  configuration 
INSTALLED_APPS. 

Una  vez  que  has  hecho  eso,  carga  las  etiquetas  con  {%  load  humanize  %}  en  una 
plantilla,  y tendras  acceso  a los  filtros  que  se  describen  en  las  siguientes  secciones. 

apnumber 

Para  numeros  entre  1 y 9,  este  filtro  retorna  la  representacion  textual  del  numero. 
Caso  contrario  retorna  el  numeral.  Esto  cumple  con  el  estilo  Associated  Press. 

Ejemplos: 

■ 1 se  convierte  en  uno. 

■ 2 se  convierte  en  dos. 

■ 0 se  convierte  en  10. 

Puedes  pasarle  ya  sea  un  entero  o una  representacion  en  cadena  de  un  entero. 

intcomma 


Este  filtro  convierte  un  entero  a una  cadena  conteniendo  comas  cada  tres  digitos. 
Ejemplos: 

■ 4500  se  convierte  en  4,500. 

■ 45000  se  convierte  en  45,000. 
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■ 450000  se  convierte  en  450,000. 

■ 4500000  se  convierte  en  4,500,000. 

Puedes  pasarle  ya  sea  un  entero  o una  representacion  en  cadena  de  un  entero. 

intword 

Este  filtro  convierte  un  entero  grande  a una  representacion  amigable  en  texto. 
Funciona  mejor  con  numeros  mayores  a un  millon. 

Ejemplos: 

■ 1000000  se  convierte  en  1.0  millon. 

■ 1200000  se  convierte  en  1.2  millon. 

■ Se  admiten  valores  hasta  de  10A100  (Googol). 

Puedes  pasarle  ya  sea  un  entero  o una  representacion  en  cadena  de  un  entero. 

naturalday 


Este  filtro  se  usa  para  mostrar  fechas  por  ejemplo  hoy,  manana  o ayer.  Tomando 
como  valor  la  fecha  del  dia  de  hoy. 

Ejemplos  (cuando  la  etiqueta  ‘now’  es  17  Feb  2007): 

■ 16  Feb  2007  se  convierte  en  aller. 

■ 17  Feb  2007  se  convierte  en  hoy. 

■ 18  Feb  2007  se  convierte  en  manana. 

Cualquier  otro  dia  se  formatea  segun  el  argumento  dado  o configurado  en 
DATE_FORMAT  si  no  se  da  ningun  argumento. 

Argumentos:  Una  fecha  formateada  como  una  cadena. 

naturaltime 

Este  filtro  se  usa  para  mostrar  valores  de  tiempo,  retorna  una  cadena  que  representa 
cuantos  segundos,  minutos  y horas  han  pasado  -recurre  al  formato  de  la  etiqueta 
timesince  si  el  valor  tiene  mas  de  un  dia.  En  este  caso  retorna  el  valor  usando  una 
frase. 

Ejemplo  (cuando  la  etiqueta  ‘now’  es  17  Feb  2007  16:30:00): 

■ 17  Feb  2007  16:30:00  se  convierte  en  ahora. 

■ 17  Feb  2007  16:29:31  se  convierte  en  hace  29 

■ 17  Feb  2007  16:29:00  se  convierte  en  hace  un  minuto. 

■ 17  Feb  2007  16:25:35  se  convierte  en  hace  4 minutos. 

■ 17  Feb  2007  15:30:29  se  convierte  en  Hace  59  minutos. 

ordinal 

Este  filtro  convierte  un  entero  a una  cadena  cuyo  valor  es  su  ordinal. 

Ejemplos: 

■ 1 se  convierte  en  1st. 

■ 2 se  convierte  en  2nd. 
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■ 3 se  convierte  en  3rd. 

Puedes  pasarle  ya  sea  un  entero  o una  representation  en  cadena  de  un  entero. 


^Que  sigue? 


Muchos  de  estos  frameworks  contribuidos  (CSRF,  el  sistema  de  autenticacion,  etc.) 
hacen  su  magia  proveyendo  una  pieza  de  middleware.  El  middleware  es 
esencialmente  codigo  que  se  ejecuta  antes  y/o  despues  de  cada  peticion  y puede 
modificar  cada  peticion  y respuesta  a voluntad.  A continuation  trataremos  el 
middleware  incluido  con  Django  y explicaremos  como  puedes  crear  tu  propio 
middleware. 
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Middleware 


En  ocasiones,  necesitar^s  ejecutar  una  pieza  de  codigo  en  todas  las  peticiones  que 
maneja  Django.  Este  codigo  puede  necesitar  modificar  la  peticion  antes  de  que  la 
vista  se  encargue  de  ella,  puede  necesitar  registrar  information  sobre  la  peticion  para 
propositos  de  debugging,  y asi  sucesivamente. 

Tu  puedes  hacer  esto  con  el  framework  middleware  de  Django,  que  es  un 
conjunto  de  acoples  dentro  del  procesamiento  de  peticion/respuesta  de  Django.  Es 
un  sistema  de  “plug-in”  liviano  y de  bajo  nivel  capaz  de  alterar  de  forma  global  tanto 
la  entrada  como  la  salida  de  Django. 

Cada  componente  middleware  es  responsable  de  hacer  alguna  funcion  especifica. 
Si  estas  leyendo  este  libro  de  forma  lineal  (disculpen,  posmodernistas),  has  visto 
middleware  varias  veces  ya: 

Todas  las  herramientas  de  usuario  y sesion  que  vimos  en  el  capitulo  14  son 
posibles  gracias  a unas  pequenas  piezas  de  middleware  (mas  especificamente,  el 
middleware  hace  que  request.session  y request.user  esten  disponibles  para  ti  en  las 
vistas. 

La  cache  global  del  sitio  discutida  en  el  capitulo  15  es  solo  una  pieza  de 
middleware  que  desvia  la  llamada  a tu  funcion  de  vista  si  la  respuesta  para  esa  vista 
ya  fue  almacenada  en  la  cache. 

Todas  las  aplicaciones  del  paquete  contrib  como  flatpages,  redirects,  y csrf  del 
capitulo  76’hacen  su  magia  a traves  de  componentes  middleware. 

En  este  capitulo  nos  sumergiremos  en  las  profundidades  del  middleware  y 
conoceremos  exactamente  como  funciona,  y te  explicaremos  como  puedes  escribir 
tu  propio  middleware. 


^Que  es  el  Middleware? 


Un  componente  middleware  es  simplemente  una  clase  Python  que  se  ajusta  a una 
cierta  API.  Antes  de  entrar  en  los  aspectos  formales  de  los  que  es  esa  API,  miremos  un 
ejemplo  muy  sencillo. 

Sitios  de  traflco  alto  a menudo  necesitan  implementar  Django  detras  de  un  proxy 
de  balanceo  de  carga  (mira  el  capitulo  12).  Esto  puede  causar  unas  pequenas 
complicaciones,  una  de  las  cuales  es  que  la  IP  remota  de  cada  peticion 
(request.META[“REMOTE_IP”]j  sera  la  del  balanceador  de  carga,  no  la  IP  real  que 
realiza  la  peticion.  Los  balanceadores  de  carga  manejan  esto  estableciendo  una 
cabecera  especial,  X-Forwarded-For,  con  el  valor  real  de  la  direccion  IP  que  realiza  la 
peticion. 

Asi  que  aqui  esta  una  pequena  parte  de  middleware  que  le  permite  a los  sitios  que 
se  ejecutan  detras  de  un  proxy  ver  la  direccion  IP  correcta  en 
request.META[“REMOTE_ADDR”] : 
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class  SetRemoteAddrFromForwardedFor(object): 
def  process_request(self,  request): 
try 

realjp  = request.  META['HTTP_X_FORWARDED_FOR'] 
except  KeyError: 
pass 
else: 

# HTTP_X_FORWARDED_FOR  puede  ser  una  lista  de  IP's  separadas 

# por  comas.  Toma  la  primera  IP  que  encuentra. 
realjp  = realjp.  split(",")[0] 


(Nota:  Aunque  las  cabeceras  HTTP  son  llamadas  X-Forwarded-For,  Django  hace 
que  esten  disponibles  como  request.META['HTTP_X_FORWARDED_FOR'].  Con  la 
exception  de  content-length  y content-type,  cualquier  cabecera  HTTP  en  la  petition 
es  convertida  en  una  clave  request.META  convirtiendo  todos  los  caracteres  a 
mayusculas,  remplazando  cualquier  guion  con  guiones  bajos  y agregando  el  prefijo 
HTTP_  al  nombre. 

Si  el  middleware  esta  instalado  (mira  la  siguiente  seccion),  el  valor  de  de  todas  las 
peticiones  X-Forwarded-For  sera  automaticamente  insertado  en 
request.META['REMOTE_ADDR'].  Esto  significa  que  tus  aplicaciones  Django  no 
necesitan  conocer  si  estan  detras  de  un  proxy  de  balanceo  de  carga  o no,  pueden 
simplemente  acceder  a request.META['REMOTE_ADDR'],  y eso  funcionara  si  se  usa 
un  proxy  o no. 

De  hecho,  es  una  necesidad  tan  comun,  que  esta  pieza  de  middleware  ya  viene 
incorporada  en  Django.  Esta  ubicada  en  django.middleware.http,  y puedes  leer  mas 
sobre  ella  en  la  siguiente  seccion. 


Instalacion  de  Middleware 

Si  has  leido  este  libro  completamente  hasta  aqui,  ya  has  visto  varios  ejemplos  de 
instalacion  de  middleware;  muchos  de  los  ejemplos  en  los  capitulos  previos  han 
requerido  cierto  middleware.  Para  completar,  a continuation  se  muestra  la  manera 
de  instalar  middleware. 

Para  activar  algun  componente  del  middleware,  solo  agregalo  a la  tupla 
MIDDLEWARE_CLASSES  en  tu  archivo  de  configuration.  En 
MIDDLEWARE_CLASSES,  cada  componente  middleware  se  representa  con  una 
cadena:  la  ruta  Python  completa  al  nombre  de  la  clase  middleware.  Por  ejemplo,  aqui 
se  muestra  la  tupla  MIDDLEWARE_CLASSES  por  omision  creada  por  django- 
admin.py  startproject: 

MIDDLEWARE_CLASSES  = ( 

'django. contrib. sessions,  middleware. SessionMiddleware', 

'django.  middleware. common. CommonMiddleware', 

'django.  middleware. csrf.CsrfViewMiddleware', 

'django. contrib. auth. middleware.  AuthenticationMiddleware', 

'django. contrib.  messages. middleware.  MessageMiddleware', 

'django.  middleware. clickjacking. XFrameOptionsMiddleware', 

) 


Una  instalacion  Django  no  requiere  ningun  middleware  - La  tupla 
MIDDLEWARE_CLASSES  puede  estar  vacia,  si  tu  quieres,  pero  te  recomendamos  que 
actives  CommonMiddleware,  la  cual  explicaremos  en  breve. 
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El  orden  es  importante.  En  las  fases  de  peticion  y vista,  Django  aplica  el  middleware 
en  el  orden  que  figura  en  MIDDLEWARE_CLASSES,  y en  las  fases  de  respuesta  y 
excepcion,  Django  aplica  el  middleware  en  el  orden  inverso.  Es  decir,  Django  trata 
MIDDLEWARE_CLASSES  como  una  especie  de  “wrapper”  alrededor  de  la  funcion  de 
vista:  en  la  peticion  recorre  hacia  abajo  la  lista  hasta  la  vista,  y en  la  respuesta  la 
recorre  hacia  arriba. 

Mira  la  siguiente  figura  para  un  repaso  de  las  fases  y el  orden  que  sigue  el 
middleware  en  una  peticion. 


Figura  17-1.  Orden  de  Middleware  en  Django. 

Como  puedes  observar,  durante  la  fase  de  peticion  (request),  antes  de  llamar  a la 
vista,  Django  aplica  el  Middleware  en  el  orden  definido  en  la  tupla 
MIDDLEWARE_CLASSES.  De  arriba  hacia  abajo.  Mediante  dos  ganchos  disponibles: 

1.  process_request() 

2.  process_viewO 

Durante  la  fase  de  respuesta,  despues  de  llamar  a la  vista,  el  middleware  es 
aplicado  en  orden  inverso  de  abajo  hacia  arriba,  Usando  tres  ganchos  disponibles: 

■ process_exception()  (unicamente  si  la  vista  lanza  una  excepcion) 

■ process_template_response()  (unicamente  para  la  respuesta  de  la  plantilla) 

■ process_response() 

Puedes  pensar  en  este  proceso,  como  si  fuera  una  cebolla,  donde  cada  clase  del 
middleware  es  una  capa  que  envuelve  la  vista. 
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Metodos  de  un  Middleware 


Ahora  que  sabes  que  es  un  middleware  y como  instalarlo,  echemos  un  vistazo  a todos 
los  metodos  disponibles  que  las  clases  middleware  pueden  definir. 

Initializar: init (self) 

Utiliza  init ()  para  realizar  una  configuration  a nivel  de  sistema  de  una 

determinada  clase  middleware. 

Por  razones  de  rendimiento,  cada  clase  middleware  activada  es  instanciada  solo 

una  vezpor  proceso  servidor.  Esto  significa  que init ()  es  llamada  solo  una  vez  - al 

iniciar  el  servidor,  no  para  peticiones  individuales. 

Una  razon  comun  para  implementar  un  metodo init ()  es  para  veriflcar  si  el 

middleware  es  en  realidad  necesario.  Si  init ()  emite 

django.  core,  exceptions.  MiddlewareNotUsed,  entonces  Django  removera  el 

middleware  de  la  pila  de  middleware.  Tu  podrias  usar  esta  caracteristica  para 
veriflcar  si  existe  una  pieza  de  software  que  la  clase  middleware  requiere,  o veriflcar  si 
el  servidor  esta  ejecutandose  en  modo  debug,  o cualquier  otra  situation  similar. 

Si  una  clase  middleware  define  un  metodo  init (),  este  no  debe  tomar 

argumentos  mas  alia  del  estandar  self. 

Pre-procesador  de  peticion:  process_request(self,  request) 

Este  metodo  es  llamado  tan  pronto  como  la  peticion  ha  sido  recibida  - antes  de  que 
Django  haya  analizado  sintacticamente  la  URL  para  determinar  cual  vista  ejecutar.  Si 
se  le  pasa  el  objeto  HttpRequest,  el  cual  puedes  modificar  a tu  voluntad, 
process_request()  debe  retornar  ya  sea  None  o un  objeto  HttpResponse. 

Si  devuelve  None,  Django  continuara  procesando  esta  peticion,  ejecutando 
cualquier  otro  middleware  y la  vista  apropiada. 

Si  devuelve  un  objeto  HttpResponse,  Django  no  se  encargara  de  llamar  a cualquier 
otro  middleware  (de  ningun  tipo)  o a la  vista  apropiada.  Django  inmediatamente 
devolvera  ese  objeto  HttpResponse. 

Pre-procesador  de  vista:  process_view(self,  request,  view,  args, 

kwargs) 

Este  metodo  es  llamado  despues  de  la  llamada  al  pre-procesador  de  peticion  y 
despues  de  que  Django  haya  determinado  que  vista  ejecutar,  pero  antes  de  que  esa 
vista  sea  realmente  ejecutada. 

Los  argumentos  que  se  pasan  a esta  vista  son  mostrados  en  la  Tabla  15-1. 


Argumento  Explication 


request  El  objeto  HttpRequest. 

view  La  funcion  Python  que  Django  llamara  para  manejar  esta  peticion.  Este 

es  en  realidad  el  objeto  funcion  en  si,  no  el  nombre  de  la  funcion  como 
string. 

args  La  lista  de  argumentos  posicionales  que  seran  pasados  a la  vista,  no 

incluye  el  argumento  request  (el  cual  es  siempre  el  primer  argumento 
de  una  vista). 

kwargs  El  diccionario  de  palabras  clave  argumento  que  sera  pasado  a la  vista. 


Tabla  17-1.  Argumentos  que  se  pasan  a process_view() 
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Asi  como  el  metodo  process_request(),  process_view()  debe  retornar  ya  sea  None 
o un  objeto  HttpResponse. 

■ Si  devuelve  None,  Django  continuara  procesando  esta  peticion, 
ejecutando  cualquier  otro  middleware  y la  vista  apropiada. 

■ Si  devuelve  un  objeto  HttpResponse,  Django  no  se  encargara  de  llamar  a 
cualquier  otro  middleware  (de  ningun  tipo)  o a la  vista  apropiada.  Django 
inmediatamente  devolvera  ese  objeto  HttpResponse. 


Pos-procesador  de  respuesta:  process_response(self,  request, 

response) 

Este  metodo  es  llamado  despues  de  que  la  funcion  de  vista  es  llamada  y la  respuesta 
generada. 

Aqui,  el  procesador  puede  modiflcar  el  contenido  de  una  respuesta;  un  caso  de 
uso  obvio  es  la  compresion  de  contenido,  como  por  ejemplo  la  compresion  con  gzip 
del  HTML  de  la  respuesta. 

Los  parametros  deben  ser  bastante  auto-explicativos:  request  es  el  objeto  peticion, 
y response  es  el  objeto  respuesta  retornados  por  la  vista. 

A diferencia  de  los  pre-procesadores  de  peticion  y vista,  los  cuales  pueden 
retornar  None,  process_response()  debe  retornar  un  objeto  HttpResponse.  Esa 
respuesta  puede  ser  la  respuesta  original  pasada  a la  funcion  (posiblemente 
modificada)  o una  totalmente  nueva. 


Pos-procesador  de  excepcion:  process_exception(self,  request, 

excepcion) 

Este  metodo  es  llamado  solo  si  ocurre  algun  error  y la  vista  emite  una  excepcion  sin 
capturar. 

Puedes  usar  este  metodo  para  enviar  notificaciones  de  error,  volcar  information 
postmortem  a un  registro,  o incluso  tratar  de  recuperarse  del  error  automaticamente. 

Los  parametros  para  esta  funcion  son  el  mismo  objeto  request  con  el  que  hemos 
venido  tratando  hasta  aqui,  y excepcion,  el  cual  es  el  objeto  Exception  real  emitido 
por  la  funcion  de  vista. 

process_exception()  debe  retornar  ya  sea  None  o un  objeto  HttpResponse. 

• Si  devuelve  None,  Django  continuara  procesando  esta  peticion  con  el 
manejador  de  excepcion  incorporado  en  el  framework. 

• Si  devuelve  un  objeto  HttpResponse,  Django  usara  esa  respuesta  en  vez  del 
manejador  de  excepcion  incorporado  en  el  framework. 


Nota:  Django  trae  incorporado  una  serie  de  clases  middleware  (que  se  discuten 
en  la  section  siguiente)  que  hacen  de  buenos  ejemplos.  La  lectura  de  su  codigo 
deberia  darte  una  buena  idea  de  la  potencia  del  middleware. 

Tambien  puedes  encontrar  una  serie  de  ejemplos  contribuidos  por  la  comunidad  en 
el  wiki  de  Django:  http: / / code.djangoproject.com/wiki/ContributedMiddleware 
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Middleware  incorporado 

Django  viene  con  algunos  middleware  incorporados  para  lidiar  con  problemas 
comunes,  los  cuales  discutiremos  en  las  secciones  que  siguen. 

Middleware  de  soporte  para  autenticacion 

Clase  middleware:  django.contrib.auth. middleware.  Authentication  Middleware. 

Este  middleware  permite  el  soporte  para  autenticacion.  Agrega  el  atributo 
request.user,  que  representa  el  usuario  actual  registrado,  a todo  objeto  HttpRequest 
que  se  recibe. 

Mira  el  capitulo  A?  para  los  detalles  completos. 

“Common”  Middleware 

Clase  middleware:  django. middleware. common. CommonMiddleware. 

Este  middleware  agrega  algunas  conveniencias  para  los  perfeccionistas: 

• Prohlbe  el  acceso  a los  agentes  de  usuario  especificados  en  la  configuracidn 
DISALLOWED_USER_AGENTS:  Si  se  especifica,  esta  configuracidn  deberia  ser 
una  lista  de  objetos  de  expresiones  regulares  compiladas  que  se  comparan 
con  el  encabezado  user-agent  de  cada  peticion  que  se  recibe.  Aqui  esta  un 
pequeno  ejemplo  de  un  archivo  de  configuracidn: 

import  re 

DISALLOWED_USER_AGENTS  = ( 
re.compile(r'AOmniExplorer_Bot'), 
re.compile(r'AGooglebot') 

) 

Nota  el  import  re,  ya  que  DISALLOWED_USER_AGENTS  requiere  que  sus 
valores  sean  expresiones  regulares  compiladas  (es  decir,  el  resultado  de 
re.compileO).  El  archivo  de  configuracidn  es  un  archivo  comun  de  Python,  por 
lo  tanto  es  perfectamente  adecuado  incluir  sentencias  import  en  el. 

• Realiza  re-escritura  de  URL  basado  en  las  configuraciones  APPEND_SLASE1  y 
PREPEND_WWW:  Si  APPEND_SLASE1  es  igual  a True,  las  URLs  que  no  poseen 
una  barra  al  final  seran  redirigidas  a la  misma  URL  con  una  barra  al  final,  a 
menos  que  el  ultimo  componente  en  el  path  contenga  un  punto.  De  esta 
manera  foo.com/bar  es  redirigido  a foo.com/bar/,  pero  foo.com/bar/file.txt 
es  pasado  a traves  sin  cambios. 

Si  PREPEND_WWW  es  igual  a True,  las  URLs  que  no  poseen  el  prefijo  “www.” 
seran  redirigidas  a la  misma  URL  con  el  prefijo  “www.”. 

Ambas  opciones  tienen  por  objeto  normalizar  URLs.  La  filosofia  es  que  cada 
URL  deberia  existir  en  un  - y solo  un  - lugar.  Tecnicamente  la  URL 
example.com/bar  es  distinta  de  example.com/bar/,  la  cual  a su  vez  es  distinta 
de  www.example.com/bar/.  Un  motor  de  busqueda  indexador  trataria  de 
forma  separada  estas  URLs,  lo  cual  es  perjudicial  para  la  valoracion  de  tu  sitio 
en  el  motor  de  busqueda,  por  lo  tanto  es  una  buena  practica  normalizar  las 
URLs. 
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• Maneja  ETags  basado  en  la  configuration  USE_ETAGS:  ETags  es  una 
optimization  a nivel  EITTP  para  almacenar  condicionalmente  las  paginas  en 
la  cache.  Si  USE_ETAGS  es  igual  a True,  Django  calculara  una  ETag  para  cada 
peticion  mediante  la  generation  de  un  hash  MD5  del  contenido  de  la  pagina, 
y se  hara  cargo  de  enviar  respuestas  Not  Modified,  si  es  apropiado. 

Nota:  tambien  existe  un  middleware  de  GET  condicional,  que  veremos  en 
breve,  el  cual  maneja  ETags  y hace  algo  mas. 


Middleware  de  compresion 

Clase  middleware:  django. middleware. gzip.GZipMiddleware. 

Este  middleware  comprime  automaticamente  el  contenido  para  aquellos 
navegadores  que  comprenden  la  compresion  gzip  (todos  los  navegadores  modernos). 
Esto  puede  reducir  mucho  la  cantidad  de  ancho  de  banda  que  consume  un  servidor 
Web.  La  desventaja  es  que  esto  toma  un  poco  de  tiempo  de  procesamiento  para 
comprimir  las  paginas. 

Nosotros  por  lo  general  preferimos  velocidad  sobre  ancho  de  banda,  pero  si  tu 
prefieres  lo  contrario,  solo  habilita  este  middleware. 


Middleware  de  GET  condicional 

Clase  middleware:  django. middleware. http. ConditionalGetMiddleware. 

Este  middleware  provee  soporte  para  operaciones  GET  condicionales.  Si  la 
respuesta  contiene  un  encabezado  Last-Modified  o ETag,  y la  peticion  contiene  If- 
None-Match  o If-Modified-Since,  la  respuesta  es  reemplazada  por  una  respuesta  304 
(“Not  modified”).  El  soporte  para  ETag  depende  de  la  configuration  USE_ETAGS  y 
espera  que  el  encabezado  ETag  de  la  respuesta  ya  este  previamente  fijado.  Como  se 
senalo  anteriormente,  el  encabezado  ETag  es  fijado  por  el  middleware  Common. 

Tambien  elimina  el  contenido  de  cualquier  respuesta  a una  peticion  E1EAD  y flja 
los  encabezados  de  respuesta  Date  y Content- Length  para  todas  las  peticiones. 

Soporte  para  uso  de  proxy  inverso  (Middleware  X-Forwarded-For) 


Clase  middleware:  django. middleware.http.SetRemoteAddrFromForwardedFor. 

Este  es  el  ejemplo  que  examinamos  en  la  section  anterior  “Que  es  middleware”. 
Este  establece  el  valor  de  request.META['REMOTE_ADDR']  basandose  en  el  valor  de 
request.META[’ElTTP_X_FORWARDED_FOR'],  si  este  ultimo  esta  fijado.  Esto  es  util  si 
estas  parado  detras  de  un  proxy  inverso  que  provoca  que  cada  peticion 
REMOTE_ADDR  seafijadaa  127.0.0.1. 


% Advertencia:  Este  middleware  no  permile  validar  HTTP_X_FORWARDED_FOR. 

Si  no  estas  detras  de  un  proxy  inverso  que  establece  HTTP_X_FORWARDED_FOR 
automaticamente,  no  uses  este  middleware.  Cualquiera  puede  inventar  el  valor  de 
HTTP_X_FORWARDED_FOR,  y ya  que  este  establece  REMOTE_ADDR  basandose  en 
HTTP_X_FORWARDED_FOR,  significa  que  cualquiera  puede  falsear  su  direction  IP. 

Solo  usa  este  middleware  cuando  confies  absolutamente  en  el  valor  de 
HTTP_X_FORWARDED_FOR. 
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Middleware  de  soporte  para  sesiones 

Clase  middleware:  django.contrib. sessions. middleware. SessionMiddleware. 

Este  middleware  habilita  el  soporte  para  sesiones.  Mira  el  capltulo  14  para  mas 
detalles. 

Middleware  de  cache  de  todo  el  sitio 

Clase  middleware:  django. middleware. cache. CacheMiddleware. 

Este  middleware  almacena  en  la  cache  cada  pagina  impulsada  por  Django.  Este  se 
analizo  en  detalle  en  el  capltulo  15. 

Middleware  de  transaccion 

Clase  middleware:  django. middleware. transaction. TransactionMiddleware. 

Este  middleware  asocia  un  COMMIT  o ROLLBACK  de  la  base  de  datos  con  una 
fase  de  peticion/respuesta.  Si  una  vista  de  funcion  se  ejecuta  con  exito,  se  emite  un 
COMMIT.  Si  la  vista  provoca  una  exception,  se  emite  un  ROLLBACK. 

El  orden  de  este  middleware  en  la  pila  es  importante.  Los  modulos  middleware 
que  se  ejecutan  fuera  de  este,  se  ejecutan  con  commit-on-save  - el  comportamiento 
por  omision  de  Django.  Los  modulos  middleware  que  se  ejecutan  dentro  de  este 
(proximos  al  final  de  la  pila)  estaran  bajo  el  mismo  control  de  transaccion  que  las 
vistas  de  funcion. 

Mira  el  Apendice  B para  obtener  mas  information  sobre  las  transacciones  de  base 
de  datos. 

Middleware  “X-View” 

Clase  middleware:  django. middleware. doc. XViewMiddleware. 

Este  middleware  envia  cabeceras  HTTP  X-View  personalizadas  a peticiones  HEAD 
que  provienen  de  direcciones  IP  definidas  en  la  configuration  INTERNAL_IPS.  Esto 
es  usado  por  el  sistema  automatico  de  documentation  de  Django. 


^Que  sigue? 

Los  desarrolladores  Web  y los  disenadores  de  esquemas  de  bases  de  datos  no  siempre 
tienen  el  lujo  de  comenzar  desde  cero.  En  el  proximo  capltulo,  vamos  a cubrir  el 
modo  de  integrar  Django  con  sistemas  existentes,  tales  como  esquemas  de  bases  de 
datos  que  has  heredado  de  la  decada  de  los  80. 
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Integracion  con  base  de  datos 
y aplicaciones  existentes 

Django  es  el  mas  adecuado  para  el  desarrollo  denominado  de  campo  verde  - es 
decir,  comenzar  proyectos  desde  cero,  como  si  estuvieramos  construyendo  un 
edificio  en  un  campo  fresco  de  pasto  verde.  Pero  a pesar  de  que  Django  favorece  a los 
proyectos  iniciados  desde  cero,  es  posible  integrar  el  framework  con  bases  de  datos  y 
aplicaciones  existentes.  Este  capitulo  explica  algunas  de  las  estrategias  de 
integracion. 

Integracion  con  una  base  de  datos  existente 


La  capa  de  base  de  datos  de  Django  genera  esquemas  SQL  desde  codigo  Python  - 
pero  con  una  base  de  datos  existente,  tu  ya  tienes  los  esquemas  SQL.  En  tal  caso, 
necesitas  crear  modelos  para  tus  tablas  de  la  base  de  datos  existente.  Para  este 
proposito,  Django  incluye  una  herramienta  que  puede  generar  el  codigo  del  modelo 
leyendo  el  diseno  de  las  tablas  de  la  base  de  datos.  Esta  herramienta  se  llama 
inspectdb,  y puedes  llamarla  ejecutando  el  comando  manage.py  inspectdb. 


Usando  inspectdb 

La  utilidad  inspectdb  realiza  una  introspection  de  la  base  de  datos  a la  que  apunta  tu 
archivo  de  configuracion,  determina  una  representation  del  modelo  que  usara 
Django  para  cada  una  de  tus  tablas,  e imprime  el  codigo  Python  del  modelo  a la 
salida  estandar. 

Esta  es  una  guia  de  un  proceso  tipico  de  integracion  con  una  base  de  datos 
existente  desde  cero.  Las  unicas  suposiciones  son  que  Django  esta  instalado  y tienes 
una  base  de  datos  existente. 

1.  Crea  un  proyecto  Django  ejecutando  django-admin.py  startproject  mi_sitio 
(donde  mi_sitio  es  el  nombre  de  tu  proyecto).  Usaremos  mi_sitio  como  el 
nombre  de  nuestro  proyecto,  en  este  ejemplo. 

2.  Edita  el  archivo  de  configuracion  en  ese  proyecto,  mi_sitio/settings.py,  para 

decide  a Django  cuales  son  los  parametros  de  conexion  a tu  base  de  datos  y 
cual  es  su  nombre.  Especificamente,  provee  las  configuraciones  de 
DATABASE_NAME,  DATABASE_ENGINE,  DATABASES SLR, 

DATABASE_PASSWORD,  DATABASE_HOST,  y DATABASE_PORT.  (Ten  en 
cuenta  que  algunas  de  estas  configuraciones  son  opcionales,  ya  que  dependen 
de  la  base  de  datos  a usar.  Mira  el  capitulo  5para  mas  information). 
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3.  Crea  una  aplicacion  dentro  de  tu  proyecto  ejecutando  python 
rn Ls i ti o / m a n age . p y startapp  myapp  (donde  myapp  es  el  nombre  de  tu 
aplicacion).  Usaremos  myapp  como  el  nombre  de  aplicacion  aqul. 

4.  Ejecuta  el  comando  python  mi_sitio/manage.py  inspectdb.  Esto  examinara 
las  tablas  en  la  base  de  datos  DATABASE_NAME  e imprimira  para  cada  tabla 
el  modelo  de  clase  generado.  Dale  una  mirada  a la  salida  para  tener  una  idea 
de  lo  que  puede  hacer  inspectdb. 

5.  Guarda  la  salida  en  el  archivo  models.py  dentro  de  tu  aplicacion  usando  la 
redirection  de  salida  estandar  de  la  shell: 

python  mi_sitio/manage.py  inspectdb  > mi_sitio/myapp/models.py 

6.  Edita  el  archivo  mi_sitio/myapp/models.py  para  limpiar  los  modelos 
generados  y realiza  cualquier  personalization  necesaria.  Te  daremos  algunas 
sugerencias  para  esto  en  la  siguiente  section. 

Limpiar  los  modelos  generados 

Como  podrias  esperar,  la  introspection  de  la  base  de  datos  no  es  perfecta,  y 
necesitaras  hacer  una  pequena  limpieza  al  codigo  del  modelo  resultante.  Aqul  hay 
algunos  apuntes  para  lidiar  con  los  modelos  generados: 

• Cada  tabla  de  la  base  de  datos  es  convertida  en  una  clase  del  modelo  (es  decir, 
hay  un  mapeo  de  uno-a-uno  entre  las  tablas  de  la  base  de  datos  y las  clases  del 
modelo).  Esto  significa  que  tendras  que  refactorizar  los  modelos  para  tablas 
con  relaciones  muchos-a-muchos  en  objetos  ManyToManyField. 

• Cada  modelo  generado  tiene  un  atributo  para  cada  campo,  incluyendo 
campos  de  clave  primaria  id.  Sin  embargo,  recuerda  que  Django  agrega 
automaticamente  un  campo  de  clave  primaria  id  si  un  modelo  no  tiene  una 
clave  primaria.  Por  lo  tanto,  es  necesario  remover  cualquier  linea  que  se 
parezca  a esta: 

id  = models. lntegerField(primary_key=True) 

No  solo  estas  lineas  son  redundantes,  sino  que  pueden  causar  problemas  si  tu 
aplicacion  agregara  nuevos  registros  a estas  tablas.  El  comando  inspectdb  no 
puede  detectar  si  un  campo  es  autoincrementado,  asi  que  esta  en  ti  cambiar 
esto  a AutoField,  si  es  necesario. 

• Cada  tipo  de  campo  (ej.,  CharField,  DateField)  es  determinado  mirando  el 
tipo  de  la  columna  de  la  base  de  datos  (ej.,  VARCELAR,  DATE).  Si  inspectdb  no 
puede  mapear  un  tipo  de  columna  a un  tipo  de  campo  del  modelo,  usara 
TextField  e insertara  el  comentario  Python  'This  field  type  is  a guess.'  a 
continuation  del  campo  en  el  modelo  generado.  Manten  un  ojo  en  eso,  y 
cambia  el  tipo  de  campo  adecuadamente  si  es  necesario. 

Si  un  campo  en  tu  base  de  datos  no  tiene  un  buen  equivalente  en  Django,  con 
seguridad  puedes  dejarlo  fuera.  La  capa  de  modelo  de  Django  no  requiere  que 
incluyas  todos  los  campos  de  tu(s)  tabla(s). 

• Si  un  nombre  de  columna  de  tu  base  de  datos  es  una  palabra  reservada  de 
Python  (como  pass,  class  o for),  inspectdb  agregara  '_field'  al  nombre  del 
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atributo  y establecera  el  atributo  db_column  al  nombre  real  del  campo  (ej., 
pass,  class,  o for). 

Por  ejemplo,  si  una  tabla  tiene  una  columna  INT  llamada  for,  el  modelo 
generado  tendra  un  campo  como  este: 

for_field  = models. lntegerField(db_column='for') 

inspectdb  insertara  el  comentario  Python  'Field  renamed  because  it  was  a 
Python  reserved  word.'  a continuation  del  campo. 

• Si  tu  base  de  datos  contiene  tablas  que  hacen  referencia  a otras  tablas  (como 
la  mayoria  de  las  bases  de  datos  lo  hacen),  tal  vez  tengas  que  re-acomodar  el 
orden  de  los  modelos  generados,  de  manera  que  los  modelos  que  hacen 
referencia  a otros  modelos  esten  ordenados  apropiadamente.  Por  ejemplo,  si 
un  modelo  Libro  tiene  una  ForeignKey  al  modelo  Autor,  el  modelo  Autor  debe 
ser  delinido  antes  del  modelo  Libro.  Si  necesitas  crear  una  relation  en  un 
modelo  que  todavia  no  esta  definido,  puedes  usar  el  nombre  del  modelo,  en 
vez  del  objeto  modelo  en  si. 

• inspectdb  detecta  claves  primarias  para  PostgreSQL,  MySQL  y SQLite.  Es 
decir,  inserta  primary_key=True  donde  sea  necesario.  Para  otras  bases  de 
datos,  necesitaras  insertar  primary_key=True  para  al  menos  un  campo  en 
cada  modelo,  ya  que  los  modelos  Django  requieren  tener  un  campo 
primary_key=T  rue . 

• La  detection  de  claves  foraneas  solo  funciona  con  PostgreSQL  y con  ciertos 
tipos  de  tablas  MySQL.  En  otros  casos,  los  campos  de  clave  foranea  seran 
generados  como  campos  IntegerField,  asumiendo  que  la  columna  de  clave 
foranea  fue  una  columna  INT. 


Integracion  con  un  sistema  de  autentificacion 

Es  posible  integrar  Django  con  un  sistema  de  autentificacion  existente  - otra  fuente 
de  nombres  de  usuario  y contrasenas  o metodos  de  autentificacion. 

Por  ejemplo,  tu  compania  ya  puede  tener  una  configuration  LDAP  que  almacena 
un  nombre  de  usuario  y contrasena  para  cada  empleado.  Seria  una  molestia  tanto 
para  el  administrador  de  red  como  para  los  usuarios,  si  cada  uno  de  ellos  tiene 
cuentas  separadas  en  LDAP  y en  las  aplicaciones  basadas  en  Django. 

Para  manejar  situaciones  como  esta,  el  sistema  de  autentificacion  de  Django  te 
permite  conectarte  con  otras  fuentes  de  autentificacion.  Puedes  anular  el  esquema 
por  omision  de  Django  basado  en  base  de  datos,  o puedes  usar  el  sistema  por 
omision  en  conjunto  con  otros  sistemas. 

Especificar  los  back-ends  de  autentificacion 

Detras  de  escena,  Django  mantiene  una  lista  de  “back-ends  de  autentificacion”  que 
utiliza  para  autentificar.  Cuando  alguien  llama  a django.contrib.auth.authenticate() 
(como  se  describio  en  el  capitulo  12),  Django  intenta  autentificar  usando  todos  sus 
back-ends  de  autentificacion.  Si  el  primer  metodo  de  autentificacion  falla,  Django 
intenta  con  el  segundo,  y asi  sucesivamente,  hasta  que  todos  los  back-ends  han  sido 
intentados. 
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La  lista  de  back-ends  de  autentificacion  a usar  se  especifica  en  la  configuration 
AUTHENTICATION_BACKENDS.  Esta  debe  ser  una  tupla  de  nombres  de  ruta  Python 
que  apuntan  a clases  que  saben  como  autentificar.  Estas  clases  pueden  estar  en 
cualquier  lugar  de  tu  ruta  Python. 

Por  omision,  AUTE1ENTICATI0N_BACKENDS  contiene  lo  siguiente: 
(’django.contrib.auth.  backends.  ModelBackend’,) 

Ese  es  el  esquema  basico  de  autentificacion  que  verifica  la  base  de  datos  de 
usuarios  de  Django. 

El  orden  de  AUTE1ENTICATI0N_BACKENDS  se  tiene  en  cuenta,  por  lo  que  si  el 
mismo  usuario  y contrasena  son  validos  en  multiples  back-ends,  Django  detendra  el 
procesamiento  en  la  primera  coincidencia  positiva. 


Escribir  un  back-end  de  autentificacion 


Lin  back-end  de  autentificacion  es  un  clase  que  implementa  dos  metodos: 
get_user(id)  y authenticate(**credentials). 

El  metodo  get_user  recibe  un  id  - el  cual  podria  ser  un  nombre  de  usuario,  un  ID 
de  la  base  de  datos  o cualquier  cosa  - y devuelve  un  objeto  User. 

El  metodo  authenticate  recibe  credenciales  como  argumentos  de  palabras  clave. 
La  mayoria  de  las  veces  se  parece  a esto: 

class  MyBackend(object): 

def  authenticate(self,  username=None,  password=None): 

# Verifica  el  nombre  de  usuario/contrasena  y devuelve  el  usuario. 


Pero  podria  tambien  autentificar  un  token,  como  se  muestra  a continuation: 

class  MyBackend(object): 

def  authenticate(self,  token=None): 

# Verifica  el  token  y devuelve  el  usuario. 

De  cualquier  manera,  authenticate  debe  verificar  las  credenciales  que  recibe,  y 
debe  retornar  un  objeto  User  que  coincide  con  esas  credenciales,  si  las  credenciales 
son  validas.  Si  no  son  validas,  debe  retornar  None. 

El  sistema  de  administration  de  Django  esta  altamente  acoplado  a su  propio 
objeto  User  respaldado  por  base  de  datos  descripto  en  el  capltulo  12.  La  mejor 
manera  de  lidiar  con  esto  es  crear  un  objeto  User  de  Django  para  cada  usuario  que 
existe  en  tu  back-end  (ej.,  en  tu  directorio  LDAP,  tu  base  de  datos  SQL  externa,  etc.). 
De  cualquier  manera  puedes  escribir  un  script  para  hacer  esto  por  adelantado  o tu 
metodo  de  autentificacion  puede  hacerlo  la  primera  vez  que  el  usuario  ingresa  al 
sistema. 

Aqui  esta  un  ejemplo  de  back-end  que  autentifica  contra  unas  variables  de  usuario 
y contrasena  definidas  en  tu  archivo  settings.py  y crea  un  objeto  User  de  Django  la 
primera  vez  que  un  usuario  se  autentifica: 
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from  django.conf  import  settings 

from  django.contrib.auth. models  import  User,  check_password 

class  SettingsBackend(object): 

linn 

Autentificacion  contra  la  configuracion  ADMIN_LOGIN  y ADMIN_PASSWORD. 

Usa  el  nombre  de  login,  y el  hash  del  password.  Por  ejemplo: 

ADMIN_LOGIN  = ’admin’ 

ADMIN_PASSWORD  = 

’Shal$4e987$afbcf42e21bd417fb71db8c66b321e9fc33051de’ 

min 

def  authenticate(self,  username=  \lone,  password=None): 
login_valid  = (settings.  ADMIN_LOGIN  ==  username) 
pwd_valid  = check_password(password,  settings. ADMIN_PASSWORD) 
if  login_valid  and  pwd_valid: 
try: 

user  = User,  objects.  get(username=username) 
except  User.DoesNotExist: 

# Crea  un  nuevo  usuario.  Nota  que  podemos  fijar  un  password 

# para  cualquiera,  porque  este  no  sera  comprobado;  el  password 

# de  settings. py  lo  hara. 

user  = User(username=username,  password- get  from  settings. py’) 
user.is_staff  = 
user.is_superuser  = 
user.save() 

return  user 
return  None 

def  get_user(  If,  userjd): 
try: 

return  User. objects. get(pk=user_id) 
except  User.DoesNotExist: 
return  None 


Integracion  con  aplicaciones  web  existentes 


Es  posible  ejecutar  una  aplicacion  Django  en  el  mismo  servidor  de  una  aplicacion 
impulsada  por  otra  tecnologfa.  La  manera  mas  directa  de  hacer  esto  es  usar  el  archivo 
de  configuracion  de  Apache,  httpd.conf,  para  delegar  patrones  de  URL  dife rentes  a 
distintas  tecnologias  (Nota  que  el  capitulo  12  cubre  el  despliegue  con  Django  en 
Apache /wsgi_python,  por  lo  tanto  tal  vez  valga  la  pena  leer  ese  capitulo  antes  de 
intentar  esta  integracion). 

La  clave  esta  en  que  Django  sera  activado  para  un  patron  particular  de  URL  solo  si 
tu  archivo  httpd.conf  lo  dice.  El  despliegue  por  omision  explicado  en  el  capitulo  12, 
asume  que  quieres  que  Django  impulse  todas  las  paginas  en  un  dominio  particular: 
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<Location  "/"> 

SetHandler  python -program 

Python Handler  d jango . core . handlers . mod python 
SetEnv  DJANGO_SETTINGS_MODULE  mi_sitio . settings 
PythonDebug  On 
</Location> 

Aqui,  la  linea  <Location  "/">  significa  “maneja  cada  URL,  comenzando  en  la  raiz”, 
con  Django. 

Esta  perfectamente  bien  limitar  esta  directiva  <Location>  a cierto  arbol  de 
directorio.  Por  ejemplo,  digamos  que  tienes  una  aplicacion  PHP  existente  que 
impulsa  la  mayoria  de  las  paginas  en  un  dominio  y quieres  instalar  el  sitio  de 
administracion  de  Django  en  /admin/  sin  afectar  el  codigo  PHP.  Para  hacer  esto,  solo 
configura  la  directiva  <Location>  a /admin/: 

<Location  "/admin/"> 

SetHandler  python -program 

Python Handler  d jango . core . handlers . mod python 
SetEnv  DJANGO_SETTINGS_MODULE  mi_sitio . settings 
PythonDebug  On 
</Location> 

Con  esto  en  su  lugar,  solo  las  URLs  que  comiencen  con  /admin/  activaran  Django. 
Cualquier  otra  pagina  usara  cualquier  infraestructura  que  ya  exista. 

Nota  que  adjuntar  Django  a una  URL  calificada  (como  /admin/  en  el  ejemplo  de 
esta  section)  no  afecta  a Django  en  el  analisis  de  las  URLs.  Django  trabaja  con  la  URL 
absoluta  (ej.,  /admin/people/person/add/),  no  con  una  version  “recortada”  de  la 
URL  (ej.,  /people/person/add/).  Esto  significa  que  tu  URLconf  raiz  debe  incluir  el 
prefijo  /admin/. 


<?,Que  sigue? 

Si  tu  idioma  nativo  es  el  ingles  -cosa  que  gracias  a los  traductores  ya  no  es  necesaria 
para  leer  este  libro-  quizas  no  te  hayas  enterado  de  una  de  las  mas  fantasticas 
caracteristicas  de  la  interfaz  de  administracion:  ;esta  disponible  en  mas  de  50  idiomas 
distintos!  Esto  es  posible  gracias  al  framework  de  internationalization  de  Django  (y  el 
duro  trabajo  de  los  traductores  voluntaries  de  Django).  El  Capflulolf)  explica  como 
usar  este  framework  para  crear  sitios  Django  localizados. 


CAPITULO  19 

Internationalization 


^)jango  fue  desarroltado  originalmente  en  medio  de  los  Estados  Unidos 
(literalmente;  Lawrence,  Kansas,  se  halla  a menos  de  40  millas  del  centra  geografico 
de  la  portion  continental,  de  los  Estados  Unidos).  Sin  embargo,  como  la  mayoria  de 
los  proyectos  de  codigo  abierto  ( open  source),  la  comunidad  de  Django  crecio  hasta 
incluir  a gente  de  todo  el  mundo.  A medida  que  la  comunidad  fue  tornandose  mas 
diversa,  la  internationalization  y la  localization  fueron  tomando  una  importancia 
creciente.  Debido  a que  muchos  desarrolladores  tienen,  en  el  mejor  de  los  casos,  una 
comprension  difusa  de  dichos  terminos  vamos  a definirlos  brevemente. 

El  termino  Internationalization  se  reflere  al  proceso  de  disenar  programas  para  el 
uso  potencial  de  cualquier  localidad.  Esto  incluye  marcas  de  texto  (tales  como 
elementos  de  la  interfaz  de  usuario  o mensajes  de  error)  para  su  futura  traduccion, 
abstrayendo  la  visualizacion  de  fechas  y horarios  de  manera  que  sea  posible  respetar 
diferentes  estandares  locales,  proveer  soporte  para  diferentes  zonas  horarias  y en 
general  el  asegurarse  de  que  el  codigo  no  contenga  ninguna  suposicion  acerca  de  la 
ubicacion  de  sus  usuarios.  Encontraras  a menudo  “internacionalizacion”  abreviada 
como  I18N  (el  numero  18  se  reflere  al  numero  de  letras  omitidas  entre  la  “I”  inicial  y 
la  “N”  final). 

El  termino  Localization  se  reflere  al  proceso  especifico  de  traducir  un  programa 
internacionalizado  para  su  uso  en  una  localidad  en  particular.  Encontraras  a menudo 
“localization”  abreviada  como  LION. 

Django  en  si  esta  totalmente  internacionalizado;  todas  las  cadenas  estan  marcadas 
para  su  traduccion  y existen  variables  de  configuration  que  controlan  la  visualizacion 
de  valores  locales  dependientes  como  fechas  y horarios.  Django  tambien  incluye  mas 
de  40  archivos  de  localization.  Si  no  hablas  ingles  en  forma  nativa,  existe  una  buena 
probabilidad  de  que  Django  ya  se  encuentre  traducido  a tu  idioma  nativo. 

El  mismo  framework  de  internacionalizacion  usado  para  esas  localizaciones  esta 
disponible  para  que  lo  uses  en  tu  propio  codigo  y plantillas. 

En  resumen,  necesitaras  agregar  una  cantidad  minima  de  ganchos  a tu  codigo 
Python  y a tus  plantillas.  Estos  ganchos  reciben  el  nombre  de  cadenas  de  traduction. 
Los  mismos  le  indican  a 

Django  “Este  texto  debe  ser  traducido  al  idioma  del  usuario  final  si  existe  una 
traduccion  a dicho  idioma  de  ese  texto.” 

Django  se  encarga  de  usar  estos  ganchos  para  traducir  las  aplicaciones  Web  “al 
vuelo”  de  acuerdo  a las  preferencias  de  idioma  del  usuario. 

Esencialmente,  Django  hace  dos  cosas: 

■ Le  permite  a los  desarrolladores  y autores  de  plantillas  especificar  que  partes 
de  sus  aplicaciones  deben  ser  traducibles. 


Usa  esta  information  para  traducir  las  aplicaciones  Web  para  usuarios 
particulares  de  acuerdo  a sus  preferencias  de  idioma. 
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Nota:  La  maquinaria  de  traduccion  de  Django  usa  gettext  de  GNU  ( 

(?)  http://www.gnu.org/software/gettext/)  via  el  modulo  estandar  gettext 
incluido  en  Python. 


SI  NO  NECESITAS  USAR  INTERNACIONALIZACION 


Los  ganchos  de  internacionalizacion  de  Django  se  encuentran  activos  por  omision,  lo 
cual  incurre  en  una  pequena  sobrecarga.  Si  no  utilizas  la  internacionalizacion, 
deberias  establecer  USE  I18N  = False  en  tu  archivo  de  configuracion.  Si  USE_I18N 
tiene  el  valor  False  Django  implementara  algunas  optimizaciones  de  manera  de  no 
cargar  la  maquinaria  de  localization. 

Probablemente  querras  tambien  eliminar  django.core.context_processors.il8n  de  tu 
variable  de  configuracion  TEMPLATE_CONTEXT_PROCESSORS. 

Los  tres  pasos  para  usar  la  internacionalizacion  en  aplicaciones  Django  son: 

1.  Especifica  las  cadenas  de  traduccion  en  el  codigo  Python  y en  las  plantillas. 

2.  Implementa  las  traducciones  para  esas  cadenas,  en  cualquiera  de  los 
lenguajes  que  quieras  soportar. 

3.  Activa  el  middleware  local  en  la  configuracion  de  Django. 

Cubriremos  cada  uno  de  estos  pasos  detalladamente. 


Especifica  las  cadenas  de  traduccion  en  codigo 

Python 

Las  cadenas  de  traduccion  especifican  “Este  texto  deberia  ser  traducido.”  dichas 
cadenas  pueden  aparecer  en  tu  codigo  Python  y en  tus  plantillas.  Es  tu 
responsabilidad  marcar  las  cadenas  traducibles;  el  sistema  solo  puede  traducir 
cadenas  sobre  las  que  esta  al  tanto. 

Funciones  estandar  de  traduccion 

Las  cadenas  de  traduccion  se  especifican  usando  la  funcion  ugettext().  Este  por 
convention  usa  el  alias  _ (guion  bajo),  como  un  atajo  para  importar  la  funcion. 

En  este  ejemplo,  el  texto  "Bienvenido  a mi  sitio."  esta  marcado  como  una  cadena 
de  traduccion,  usando  el  alias  _: 

from  django. utils. translation  import  ugettext  as_ 
from  django. http  import  HttpResponse 

def  mi_vista(request): 

salida  = _("Bienvenido  a mi  sitio.") 
return  HttpResponse(salida) 
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La  funcion  django.utils.translation.gettextO  es  identica  a _().  Este  ejemplo  es 
identico  al  anterior: 

from  django. utils. translation  import  ugettext 

def  mi_vista(request): 

salida  = ugettext("Bienvenido  a mi  sitio.") 
return  HttpResponse(salida) 


La  mayoria  de  los  desarrolladores  prefiere  usar  el  alias  _(),  debido  a que  es  mas 
corto. 

La  libreria  estandar  de  Python  gettext  instala  un  modulo  _()  en  el  espacio  de 
nombres  global,  como  un  alias  para  gettextO.  En  Django  hemos  decidido  no  seguir 
esta  practica  por  un  par  de  razones: 

Para  el  apoyo  internacional  del  conjunto  de  caracteres  (Unicode),  La  funcion 
django.utils.translation.ugettext  es  mas  util  que  gettextO.  Algunas  veces  puedes 
utilizar  por  defecto  la  funcion  django. utils.translation.ugettextjazy  como  metodo 
para  traducir  un  archivo  en  particular.  Sin  usar  el  _()  en  el  espacio  de  nombres  global, 
el  desarrollador  tiene  que  pensar  acerca  de  cual  es  la  funcion  mas  apropiada  para 
usar  en  la  traduccion. 

El  caracter  de  guion  bajo  (J  es  usado  para  representar  “el  resultado  previo”  en  el 
interprete  interactivo  Python  y en  las  pruebas  de  documentation.  Instalar  una 
funcion  global  _()  causa  interferencia.  Explicitamente  importando  ugettextO  como  _() 
evitamos  este  problema. 

La  traduccion  funciona  tambien  sobre  valores  computados.  Este  ejemplo  es 
identico  a los  dos  anteriores: 

def  mi_vista(request): 

palabras  = [’Bienvenido’,  'a',  ’mi’,  ’sitio.’] 
salida  = _('  .join(palabras)) 
return  HttpResponse(salida) 

La  traduccion  funciona  tambien  sobre  variables.  De  nuevo,  este  es  otro  ejemplo 
identico: 

def  mi_vista(request): 

sentencia  = ’Bienvenido  a mi  sitio.’ 
salida  = _(sentencia) 
return  HttpResponse(salida) 

(Algo  a tener  en  cuenta  cuando  se  usan  variables  o valores  computados,  como  se 
vela  en  los  dos  ejemplos  previos,  es  que  la  utilidad  de  detection  de  cadenas  de 
traduccion  de  Django,  makemessages,  no  sera  capaz  de  encontrar  esas  cadenas. 
Trataremos  el  comando  django-admin.py  makemessages  mas  adelante). 

Las  cadenas  que  le  pasas  a _()  o ugettextO  pueden  contener  marcadores  de 
position  especificados  con  la  sintaxis  estandar  de  interpolation  de  cadenas  de 
Python  con  nombres,  por  ejemplo: 

def  mi_vista(request,  m,  d): 

salida  = _(’Hoy  es  %(mes)s  %(dia)s.’)  % {’mes’:  m,  ’dia’:  d} 
return  HttpResponse(salida) 
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Esta  tecnica  permite  que  las  traducciones  especificas  de  cada  idioma  reordenen  el 
texto  de  los  marcadores  de  posicion.  Por  ejemplo,  una  traduction  al  ingles  podria  ser 
"Today  is  November  26.",  mientras  que  una  traduccion  al  espanol  podria  ser  "Hoy  es 
26  de  Noviembre.",  usando  marcadores  de  position  para  el  mes  y el  dia  para 
intercambiarlos. 

Por  esta  razon,  deberias  usar  interpolacion  de  cadenas  con  nombres  (por  ejemplo 
% (diajs)  en  lugar  de  interpolacion  posicional  (por  ejemplo  %s  o %d).  Si  usas 
interpolacion  posicional  las  traducciones  no  seran  capaces  de  reordenar  el  texto  de 
los  marcadores  de  posicion. 

Comentarios  para  traducciones 

Si  te  gustaria  darle  indicios  a los  traductores  acerca  de  una  cadena  traducible,  puedes 
anadir  un  comentario,  usando  un  prefijo  con  la  palabra  clave  Translators  en  la  linea 
anterior  a la  cadena,  por  ejemplo: 

del  mi_vista(request): 

# Translators:  Este  mensaje  aparece  en  la  pagina  de  initio  unicamente. 
output  = ugettext("Bienvenidos  a mi  sitio.") 

El  comentario  despues  aparecera  en  el  fichero  resultante  .po  asociado,  con  la 
traduccion  compilada  y localizado  debajo  de  el  mensaje  traducido,  como  en  el 
siguiente  fragmento: 

#.  Translators:  Este  mensaje  aparece  en  la  pagina  de  inicio 

unicamente . 

# path/to/python/f ile . py : 123 
msgid  "Bienvenidos  a mi  sitio." 
msgstr  "" 

Esto  tambien  funciona  en  plantillas.  Asi  como  en  el  codigo  Python,  las  notas  para 
traductores  pueden  especificarse  usando  comentarios  en  las  plantillas  de  la  siguiente 
forma. 

{%  comment  %}  Translators:  Verbo  de  la  vista  {%  endcomment  %} 

{%  trans  "Vista"  %} 

{%  comment  %}Translators:  Introduction  corta  sobre  publicidad{%  endcomment  %} 
<p>{%  blocktrans  %}Traducir  varias  lineas  de  forma  literal.{%  endblocktrans  %}</ p> 

o con  etiquetas  {#  ...  #}  uno  por  linea,  para  construir  comentarios: 

{#  Translators:  Etiqueta  de  un  boton  de  busqueda  #} 

<button  type- 'submit">{%  trans  "Ir"  %}</button> 

{#  Translators:  Este  es  texto  de  la  plantilla  base  #} 

{%  blocktrans  %}Bloque  ambiguo  de  texto  traducible{%  endblocktrans  %} 

Como  complemento,  este  es  un  fragmento  de  el  resultado  en  un  archivo  .po. 

#.  Translators:  Verbo  de  la  vista 

# ruta/a/plantilla/archivo.html:10 
msgid  "Vista" 

msgstr "" 
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#.  Translators:  Introduccion  corta  sobre  publicidad 

# path/to/template/file. html:13 
msgid 

"Traducir  varias  llneas" 

"literal." 
msgstr "" 

# ... 

#.  Translators:  Etiqueta  de  un  boton  de  busqueda 

# ruta/a/plantilla/archivo.html:100 
msgid  "Ir" 

msgstr "" 

#.  Translators:  Este  es  texto  de  la  plantilla  base 

# ruta/a/plantilla/archivo.html:103 

msgid  "bloque  ambiguo  de  texto  traducible" 
msgstr "" 


Marcando  cadenas  como  no-op 

Usa  la  funcion  django. utils. translation.ugettext_noop()  para  marcar  una  cadena 
como  una  cadena  de  traduccion  sin  realmente  traducirla  en  ese  momento.  Las 
cadenas  as!  marcadas  no  son  traducidas  sino  hasta  el  ultimo  momento  que  sea 
posible. 

Usa  este  enfoque  si  deseas  tener  cadenas  constantes  que  deben  ser  almacenadas 
en  el  idioma  original  - tales  como  cadenas  en  una  base  de  datos,  pero  que  deben  ser 
traducidas  en  el  ultimo  momento  posible,  por  ejemplo  cuando  la  cadena  es 
presentada  al  usuario. 

Traduccion  perezosa 

Usa  la  funcion  django.  uLils.  translation.  ugettextJazyO  para  traducir  cadenas  en  forma 
perezosa  - cuando  el  valor  es  accedido  en  lugar  de  cuando  se  llama  a la  funcion 
ugettext_lazy(). 

Por  ejemplo,  para  marcar  el  atributo  texto_ayuda  de  un  campo  como  traducible, 
haz  lo  siguiente: 

from  django. db  import  models 

from  django. utils. translation  import  ugettextjazy 

class  Mimodelo(models. Model): 

nombre  = models. CharField(help_text=ugettextJazy(  Este  es  el  texto  de  ayuda )) 


En  este  ejemplo,  ugettextJazyO  almacena  una  referenda  perezosa  a la  cadena  - 
no  al  verdadero  texto  traducido.  La  traduccion  en  si  misma  se  llevara  a cabo  cuando 
sea  usada  en  un  contexto  de  cadena,  tal  como  el  renderizado  de  una  plantilla  en  el 
sitio  de  administration  de  Django. 

El  resultado  de  llamar  a ugettextJazyO  puede  ser  usado  donde  se  necesite  usar 
una  cadena  en  Unicode  (un  objeto  del  tipo  Unicode)  en  Python.  Si  tratas  de  usar  un 
bytestring  donde  se  espera  un  objeto  str,  las  cosas  no  funcionaran  como  esperabas, 
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ya  que  la  funcion  ugettext_lazy()  no  puede  convertir  en  si  mismo  objetos  bytestring. 
Sin  embargo  puedes  usar  cadenas  Unicode  dentro  de  de  cualquier  bytestring  esto  es 
consistente  con  el  comportamiento  normal  de  Python. 

Por  ejemplo: 

# Esto  esta  bien:  poner  un  marcador  Unicode  dentro  de  una  cadena  Unicode. 

“Hola  %s"  % ugettext_lazy("gente") 

# Esto  no  funcionara,  ya  que  no  se  puede  insertar  un  objeto  Unicode 

# dentro  de  un  bytestring. 

b"Hola  %s"  % ugettext_lazy("gente") 

Si  ves  en  la  salida  algo  como  esto  "hola  <django. utils. functional.. .>",  estas  tratando 
de  insertar  el  resultado  de  ugettextJazyO  en  un  bytestring.  Se  trata  de  un  error  en  tu 
codigo. 

Si  no  te  gusta  el  nombre  largo  gettextjazy  puedes  simplemente  crear  un  alias  _ 
(guion  bajo)  para  el  mismo,  de  la  siguiente  forma: 

from  django.db  import  models 

from  django. utils. translation  import  ugettextjazy  as  _ 

class  Mimodelo(models. Model): 

titulo  = models. CharField(help_text=_(’Texto  de  ayuda’)) 

Usa  siempre  traducciones  perezosas  en  modelos  Django  (de  lo  contrario  no  seran 
traducidos  correctamente  para  cada  usuario).  Y es  una  buena  idea  agregar  tambien 
traducciones  de  los  nombres  de  campos  y nombres  de  tablas.  Esto  significa  que 
tambien  puedes  especificar  las  opciones  verbose_name  y verbose_name_plural  como 
traducibles  en  forma  explicita  en  la  clase  Meta,  asi: 

from  django. utils. translation  import  ugettextjazy  as  _ 
from  biblioteca.models  import  Libro 

class  Libro(models. Model): 

titulo  = models. CharField(_(’titulo’),  helpJext=_(’Escribe  el  titulo  del  libro’)) 

#.. 

class  Meta: 

verbose_name  = _(’libro’) 
verbose_name_plural  = _( libros  ) 


Pluralizacion 

Usa  la  funcion  django.utils.translation.ungettextO  para  especificar  mensajes  que 
tienen  formas  singular  y plural  distintas. 

ungettext  toma  tres  argumentos:  la  cadena  de  traduction  en  singular,  la  cadena 
de  traduction  en  plural  y el  numero  de  objetos. 

Esta  funcion  es  util  cuando  se  necesita  que  una  aplicacion  Django  sea  localizable  por 
los  lenguajes  donde  el  numero  y la  complejidad  de  las  formas  que  toma  el  plural  es 
mayor  que  las  dos  formas  usadas  en  el  ingles  (objeto  para  el  singular  y objetos  para  el 
plural,  para  casos  donde  count  es  diferente  a uno,  sin  distincion  de  su  valor.) 
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Por  ejemplo: 

from  django. utils. translation  import  ungettext 
from  django. http  import  HttpResponse 

def  ejemplo_pluralizacion(request,  count): 
page  = ungettext( 

’Este  es  %(count)d  objeto’, 

’Estos  son  %(count)d  objetos’, 
count)  % { 

’count’:  count, 

} 

return  HttpResponse(page) 


En  este  ejemplo  el  numero  de  objetos  es  pasado  al  lenguaje  de  traduccion  como  la 
variable  count. 

Observa  que  la  pluralizacion  es  complicada  y funciona  diferente  en  cada  lenguaje 
Comparar  count  con  1 no  es  siempre  la  regia  correcta.  Este  codigo  parece  sofisticado, 
pero  producira  resultados  incorrectos  en  algunos  lenguajes: 

No  intentes  implementar  tu  propia  logica  singular  o plural,  no  seria  correcto.  En 
un  caso  como  este,  considera  hacer  algo  asi  como  lo  siguiente: 


Nota:  Al  usar  ungettext  (),  asegurate  de  utilizar  un  unico  nombre  para  cada 
variable  extrapolada  incluida  literalmente.  En  los  ejemplos  anteriores,  nota 
como  utilizamos  la  variable  de  Python  nombre  en  ambas  cadenas  de  la 
traduccion.  En  el  siguiente  ejemplo,  nota  que  ademas  de  ser  incorrecto  en 
algunos  lenguajes  segun  lo  observado  anteriormente,  fallara: 

text  = ungettext( 

’Este  es  %(count)d  %(nombre)s  disponible.’, 

’Estos  son  %(count)d  %(nombre_plural)s  disponibles.’, 
count 
)%{ 

’count’:  Libro. objects. count(), 

’nombre’:  Report._meta.verbose_name, 

’nombre_plural’:  Libro._meta.verbose_name_plural 

} 


Al  ejecutar  el  comando  django-admin  compilemessages  este  retornara  un  error: 

a format  specification  for  argument  'nombre',  as  in  ' msgstr [0] ' , 
doesn't  exist  in  'msgid' 
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Cadenas  de  traduccion  en  plantillas 


Las  traducciones  en  las  plantillas  de  Django  usan  dos  etiquetas  de  plantilla  y una 
sintaxis  ligeramente  diferente  a la  del  codigo  Python.  Para  que  tus  plantillas  puedan 
acceder  a esas  etiquetas  coloca  {%  load  il8n  %}  al  principio  de  tu  plantilla. 

La  etiqueta  de  plantilla  {%  trans  %}  marcan  una  cadena  para  su  traduccion, 
(encerradas  por  comillas  simples  o dobles)  o el  contenido  de  una  variable: 

<title>{%  trans  "Este  es  el  titulo."  %}</title> 

<title>{%  trans  soyunavariable  %}</title> 

Si  la  option  noop  esta  presente,  las  operaciones  de  busqueda  de  variables  todavia 
ocurre,  pero  se  salta  la  traduccion.  Esto  es  util  cuando  el  contenido  “de  fuera” 
requiere  la  traduccion  en  el  futuro. 

<title>{%  trans  ’valor"  noop  %}</title> 

No  es  posible  mezclar  en  las  plantillas  variables  dentro  de  cadenas  sin  la  etiqueta 
{%  trans  %}  . Si  tu  traduccion  requiere  variables  (marcadores  de  position)  puedes 
usar  por  ejemplo  {%  blocktrans  %}. 

{%  blocktrans  %} 

Esta  cadena  tiene  un  {{ valor }}  dentro. 

{%  endblocktrans  %} 

Para  traducir  una  expresion  de  plantilla  - por  ejemplo,  usando  filtros  de  plantillas 
- necesitas  asociar  la  expresion  a una  variable  local  que  sera  la  que  se  usara  dentro 
del  bloque  de  traduccion: 

{%  blocktrans  with  valor|filter  as  variable  %} 

Esta  tiene  una  {{ variable  }}  dentro. 

{%  endblocktrans  %} 

Si  necesitas  asociar  mas  de  una  expresion  dentro  de  una  etiqueta  blocktrans, 
separa  las  partes  con  and: 

{%  blocktrans  with  libro|titulo  as  mijibro  and  autor|titulo  as  mi_autor  %} 

Este  es  {{  mijibro  }}  por  {{  mi_autor}} 

{%  endblocktrans  %} 

Para  pluralizar,  especifica  tanto  la  forma  singular  como  la  plural  con  la  etiqueta  {% 
plural  %}  la  cual  aparece  dentro  de  {%  blocktrans  %}  y {%  endblocktrans  %},  por 
ejemplo: 

{%  blocktrans  count  list|length  as  counter  %} 

Hay  unicamente  {{  nombre  }}  objeto. 

{%  plural  %} 

Hay  {{  counter }}  {{  nombre  }}  objetos. 

{%  endblocktrans  %} 

Internamente,  todas  las  traducciones  en  bloque  y en  linea  usan  las  llamadas 
apropiadas  a ugettext/  ungettext. 
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Cuando  usas  RequestContext  , tus  plantillas  tienen  acceso  a tres  variables 
especificas  relacionadas  con  la  traduccion: 

• {{  LANGUAGES  }}  es  una  lista  de  tuplas  en  las  cuales  el  primer  elemento  es  el 
codigo  de  idioma  y el  segundo  es  el  nombre  y escrito  usando  el  mismo). 

• {{  LANGUAGE_CODE  }}  es  el  idioma  preferido  del  usuario  actual,  expresado 
como  una  cadena  (por  ejemplo  en-us).  (Consulta  la  section  “3.  Como 
descubre  Django  la  preferencia  de  idioma”  para  information  adicional). 

• {{  LANGUAGE_BIDI  }}  es  el  sistema  de  escritura  del  idioma  actual.  Si  el  valor 
es  True,  se  trata  de  un  idioma  derecha-a-izquierda  (por  ejemplo  hebreo, 
arabe).  Si  el  valor  es  False,  se  trata  de  de  un  idioma  izquierda-a-derecha  (por 
ejemplo  ingles,  frances,  aleman). 

Si  no  usas  la  extension  RequestContext,  puedes  usar  estos  valores,  con  estas 
tres  etiquetas  de  plantilla: 

{%  get_current_language  as  LANGUAGE_CODE  %} 

{%  get_available_languages  as  LANGUAGES  %} 

{%  get_current_language_bidi  as  LANGUAGE_BIDI  %} 

Estas  etiquetas  tambien  requieren  de  {%  load  il8n  %}. 

Los  ganchos  pasa  las  traducciones  estan  disponibles  en  el  interior  de  cualquier 
etiqueta  de  bloque  de  plantilla  que  acepte  cadenas  constantes.  En  dichos  casos  basta 
con  que  uses  la  sintaxis  _()  para  especificar  que  es  una  cadena  para  traduccion,  por 
ejemplo: 

{%  alguna_etiqueta_especial  _("Pagina  no  encontrada")  value|yesno:_("si,no")  %} 

En  este  caso  tanto  la  etiqueta  como  el  filtro  veran  la  cadena  ya  traducida  (en  otras 
palabras  la  cadena  es  traducida  antes  de  ser  pasada  a las  funciones  de  manejo  de 
etiquetas),  de  manera  que  no  necesitan  estar  preparadas  para  manejar  traduccion. 


Nota:  En  este  ejemplo,  la  infraestructura  de  traducciones  pasa  la  cadena 
"si, no"  como  una  sola  y no  como  cadenas  individuales  "si"  y "no".  La  cadena 
de  traduccion  necesitara  contener  la  coma  de  modo  que  el  filtro  de  analisis 
sepa  dividir  los  argumentos.  Por  ejemplo,  una  traductor  Aleman  podria 
traducir  la  cadena  "si, no"  como  "ja,nein"  (manteniendo  la  coma  intacta). 


Trabajando  con  objetos  en  traduccion  perezosas 


El  uso  de  ugettext_lazy()  y ungettext_lazy()  para  marcar  cadenas  en  modelos  y 
funciones  de  utilidad  general  es  una  operation  muy  comun,  Cuando  trabajamos  con 
estos  objetos  en  cualquier  parte  de  nuestro  codigo,  debemos  asegurarnos  de  no 
convertir  nuestro  codigo  accidentalmente  en  cadenas,  para  ello  necesitamos 
asegurarnos  de  convertir  las  cadenas  lo  mas  tarde  posible  (de  modo  que  la  traduccion 
correcta  surta  efecto).  Esto  hace  necesario  el  uso  de  unas  par  de  funciones  de  ayuda. 
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■ string_concatO 

■ allowJazyO 


Juntando  cadenas  con:  string_concat() 

El  metodo  estandar  de  Python  join,  usado  para  juntar  cadenas  (",join([...]))  no  trabaja 
en  listas  que  contienen  traducciones  perezosas.  En  su  lugar  debes  usar 
django.utils.translation.string_concat(),  el  cual  crea  un  objeto  perezoso  que 
concatena  el  contenido  /convierte  las  cadenas  unicamente  cuando  el  resultado  es 
incluido  en  la  cadena. 

Por  ejemplo: 

from  django. utils. translation  import  string_concat 

# ... 

nombre  = ugettext_lazy(u’John  Lennon  ) 
instrumento  = ugettextjazy(u’guitarra’) 
resultado  = string_concat([nombre,  ’ instrumento]) 

En  este  caso,  la  traduccion  perezosa  en  la  variable  resultado  unicamente  convierte 
la  cadena  cuando  resultado  es  usado  en  una  cadena  (usualmente  cuando  se 
renderiza  la  plantilla) 


El  decorador  allow_lazy() 

Django  ofrece  muchas  funciones  utiles  (agrupadas  en  el  paquete  django.utils)  que 
toman  una  cadena  como  su  primer  argumento  y hacen  algo  con  la  cadena.  Estas 
funciones  son  usadas  por  los  filtros  de  plantillas  asi  como  directamente  en  el  codigo. 

Si  escribes  tus  propias  funciones  y te  ocupas  de  las  traducciones,  lo  mas  seguro  es 
que  te  has  encontrado  con  este  problema,  iQue  hacer  cuando  el  primer  argumento  es 
un  objeto  perezoso  de  una  traduccion?  Si  necesitas  convertirlo  a una  cadena 
inmediatamente,  porque  tal  vez  necesites  usarlo  fuera  de  una  funcion  de  vista  (y  por 
lo  tanto  la  configuration  actual  no  funciona) 

Para  casos  como  este,  usa  el  decorador  d j an  go . u Li  I s . fu  nc  Lio n al . al  1 o w J azy  0 El  cual 
modifica  la  funcion  si  es  llamado  con  una  traduccion  perezosa  como  su  primer 
argumento,  de  esta  forma  el  decorador  demora  la  funcion  hasta  que  necesite 
convertirse  a cadena. 

Por  ejemplo: 

from  django. utils. functional  import  allowjazy 

def  fancy_utility_function(s,  ...): 

# Hace  la  conversion  en  cadena  ’s’ 

# ... 

fancy_utility_function  = allow_lazy(fancy_utility_function,  Unicode) 

El  decorador  allowJazyO  toma,  en  adicion  a la  funcion  que  decora,  un  numero 
extra  de  argumentos  (*args)  especificando  el  tipo  que  la  funcion  original  debe 
devolver.  Usualmente,  es  suficiente  incluir  Unicode  y asegurarse  que  la  funcion 
devuelva  unicamente  cadenas  Unicode. 
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Usando  este  decorador  significa  que  puedes  escribir  tu  funcion  y asumir  que  la 
entrada  es  justamente  una  cadena,  despues  solo  agrega  el  soporte  para  traducciones 
de  objetos  perezosos  al  final. 


Como  crear  archivos  de  idioma 

Una  vez  que  hayas  etiquetado  tus  cadenas  para  su  posterior  traduccion,  necesitas 
escribir  (u  obtener)  las  traducciones  propiamente  dichas.  En  esta  section 
explicaremos  como  es  que  eso  funciona. 


RESTRICCIONES  LOCALES 


Django  no  soporta  Localization  en  una  aplicacion  local  para  la  cual  Django  en  si 
mismo  no  ha  sido  traducido.  En  este  caso  solo  ignorara  el  archivo  de  traduction.  Si 
intentas  hacer  esto  y Django  lo  soporta,  inevitablemente  veras  una  mezcla  de 
cadenas  traducidas  (de  tu  aplicacion)  y cadenas  en  Ingles  (de  Django  mismo)  Si 
quieres  soportar  el  idioma  de  tu  aplicacion  en  un  formato  local,  que  no  sea  parte  de 
Django,  necesitaras  hacer  por  lo  menos  una  traduccion  minima  del  nucleo  de 
Django. 


Creando  los  archivos  de  mensajes 

El  primer  paso  es  crear  un  archivo  de  mensajes  para  un  nuevo  idioma.  Un  archivo  de 
mensajes  es  un  archivo  de  texto  comun  que  representa  un  unico  idioma  que  contiene 
todas  las  cadenas  de  traduccion  disponibles  y como  deben  ser  representadas  las 
mismas  en  el  idioma  en  cuestion.  Los  archivos  de  mensajes  tienen  una  extension  .po. 

Django  incluye  una  herramienta,  bin/make-messages,  que  automatiza  la  creation 
y el  mantenimiento  de  dichos  archivos. 

Para  crear  o actualizar  un  archivo  de  mensajes,  ejecuta  este  comando: 

bin/make-messages. py  -I  de 

Donde  de  es  el  codigo  de  idioma  para  el  archivo  de  mensajes  que  deseas  crear.  El 
codigo  de  idioma  en  este  caso  esta  en  formato  locale.  Por  ejemplo,  el  mismo  es  pt_BR 
para  portugues  de  Brasil  y de_AT  para  aleman  de  Austria.  Echa  un  vistazo  a los 
codigos  de  idioma  en  el  directorio  django/conf/locale/  para  ver  cuales  son  los 
idiomas  actualmente  incluidos. 

El  script  debe  ser  ejecutado  desde  una  de  tres  ubicaciones: 

■ El  directorio  raiz  de  tu  proyecto  Django. 

■ El  directorio  raiz  de  tu  aplicacion  Django. 

■ El  directorio  raiz  django  (no  una  copia  de  git,  sino  el  que  se  halla  referenciado 
por  $PYTHONPATH  o que  se  encuentra  en  algun  punto  debajo  de  esa  ruta. 
Este  es  unicamente  relevante  si  estas  creando  una  traduccion  para  Django 
mismo. 

El  script  recorre  completamente  el  arbol  en  el  cual  es  ejecutado  y extrae  todas  las 
cadenas  marcadas  para  traduccion.  Crea  (o  actualiza)  un  archivo  de  mensajes  en  el 
directorio  locale/LANG/LC_MESSAGES.  En  el  ejemplo  de,  el  archivo  sera 
locale /de/LC_MESSAGES/django.po. 
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Por  defecto  django-admin.py  makemessages  examina  cada  archivo  que  tenga  una 
extension  .html.  En  el  caso  de  que  quieras  sobrescribira  el  valor  por  default  usa  la 
option  —extension  o -e  para  especilicar  la  extension  del  archivo  a examinar: 

django-admin.py  makemessages  -I  de  -e  txt 

Separa  multiples  extensiones  con  comas  y/o  usa  -e  o --extension  varias  veces: 

django-admin.py  makemessages  -I  de  -e  html, txt  -e  xml 

A1  crear  traducciones  para  catalogos  JavaScript  (el  cual  cubriremos  mas  adelante 
en  este  capitulo),  necesitaras  usar  un  dominio  especial  ‘djangojs’  no  -e  js. 


cSin  gettext? 

Si  no  tienes  instaladas  las  utilidades  gettext,  django-admin.py  makemessages 
creara  archivos  vacios.  Si  te  encuentras  ante  esa  situation  debes  o instalar 
dichas  utilidades  o simplemente  copiar  el  archivo  de  mensajes  de  ingles 
(conf/locale/en/LC_MESSAGES/django.po)  y usar  el  mismo  como  un  punto 
de  partida;  se  trata  simplemente  de  un  archivo  de  traduccion  vacio,  que  te 
servira  para  crear  el  tuyo. 


cGNU  gettext  en  Windows? 

Si  estas  usando  Windows  y necesitas  instalar  las  utilidades  GNU  gettext  para 
que  django-admin  makemessages  funcione,  consulta  la  section  “gettext  en 
Windows”  para  obtener  mas  informacion. 


El  formato  de  los  archivos  .po  es  sencillo.  Cada  archivo  .po  contiene  una  pequena 
cantidad  de  metadatos  tales  como  la  informacion  de  contacto  de  quienes  mantienen 
la  traduccion,  pero  el  grueso  del  archivo  es  una  lista  de  mensajes  - mapeos  simples 
entre  las  cadenas  de  traduccion  y las  traducciones  al  idioma  en  cuestion  propiamente 
dichas. 

Por  ejemplo,  si  tu  aplicacion  Django  contiene  una  cadena  de  traduccion  para  el 
texto  Bienvenido  a mi  sitio: 

_("Bienvenido  a mi  sitio.") 

Entonces  el  comando  django-admin.py  makemessages  creara  un  archivo  .po  que 
contendra  el  siguiente  fragmento  - un  mensaje: 

#:  ruta/a/python/module . py : 23 
msgid  "Bienvenido  a mi  sitio." 
msgstr  "" 

Es  necesaria  una  rapida  explication: 

■ msgid  es  la  cadena  de  traduccion,  la  cual  aparece  en  el  codigo  fuente.  No  la 
modifiques. 

■ msgstr  es  donde  colocas  la  traduccion  especifica  a un  idioma.  Su  valor  inicial 
es  vacio  de  manera  que  es  tu  responsabilidad  el  cambiar  esto.  Asegurate  de 
mantener  las  comillas  alrededor  de  tu  traduccion. 
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■ Por  conveniencia,  cada  mensaje  incluye  el  nombre  del  archivo  y el  numero  de 
linea  desde  el  cual  la  cadena  de  traduccion  fue  extraida. 

Los  mensajes  largos  son  un  caso  especial.  La  primera  cadena  inmediatamente  a 
continuacion  de  msgstr  (o  msgid)  es  una  cadena  vacia.  El  contenido  en  si  mismo  se 
encontrara  en  las  proximas  lineas  con  el  formato  de  una  cadena  por  linea.  Dichas 
cadenas  se  concatenan  en  forma  directa.  jNo  olvides  los  espacios  al  final  de  las 
cadenas;  en  caso  contrario  todas  seran  agrupadas  sin  espacios  entre  las  mismas! 

Por  ejemplo,  a continuacion  vemos  una  traduccion  de  multiples  lineas  (extraida 
de  la  localization  al  espanol  incluida  con  Django): 

msgid  "" 

"There's  been  an  error.  It's  been  reported  to  the  site  administrators  via  e-" 

"mail  and  should  be  fixed  shortly.  Thanks  for  your  patience." 
msgstr "" 

"Ha  ocurrido  un  error.  Se  ha  informado  a los  administradores  del  sitio  " 

"mediante  correo  electronico  y deberia  arreglarse  en  breve.  Gracias  por  su  " 
"paciencia." 

Observa  los  espacios  finales. 


TEN  EN  CUENTA  EL  CONJUNTO  DE  CARACTERES 


Cuando  crees  un  archivo  .po  con  tu  editor  de  texto  favorito,  primero  edita  la  linea  del 
conjunto  de  caracteres  (busca  por  el  texto  "CHARSET")  y fija  su  valor  al  del  conjunto 
de  caracteres  usaras  para  editar  el  contenido.  Generalmente,  UTF-8  deberia 
funcionar  para  la  mayorfa  de  los  idiomas  pero  gettext  deberia  poder  manejar 
cualquier  conjunto  de  caracteres. 

Para  reexaminar  todo  el  codigo  fuente  y las  plantillas  en  busqueda  de  nuevas 
cadenas  de  traduccion  y actualizar  todos  los  archivos  de  mensajes  para  todos  los 
idiomas,  ejecuta  lo  siguiente: 

django-admin.py  makemessages  -a 


Compilando  archivos  de  mensajes 

Luego  de  que  has  creado  tu  archivo  de  mensajes,  y cada  vez  que  realices  cambios 
sobre  el  mismo  necesitaras  compilarlo  a una  forma  mas  eficiente,  segun  los  usa 
gettext.  Usa  para  ello  la  utilidad  django-admin.py  compilemessages. 

Esta  herramienta  recorre  todos  los  archivos  .po  disponibles  y crea  archivos  .mo, 
los  cuales  son  archivos  binarios  optimizados  para  su  uso  por  parte  de  gettext.  En  el 
mismo  directorio  desde  el  cual  ejecutaste  django-admin.py  makemessages,  ejecuta 
django-admin.py  compilemessages  de  la  siguiente  manera: 

django-admin.py  compilemessages 

Y eso  es  todo.  Tus  traducciones  estan  listas  para  ser  usadas. 
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Como  descubre  Django  la  preferencia  de  idioma 

Una  vez  que  has  preparado  tus  traducciones  - o,  si  solo  deseas  usar  las  que  estan 
incluidas  en  Django,  necesitaras  activar  el  sistema  de  traduccion  para  tu  aplicacion. 
Detras  de  escena,  Django  tiene  un  modelo  muy  flexible  para  decidir  que  idioma  se 
usara  - determinado  a nivel  de  la  instalacion,  para  un  usuario  particular,  o ambas. 

Para  configurar  una  preferencia  de  idioma  a nivel  de  la  instalacion,  fija 
LANGUAGE_CODE  en  tu  archivo  de  configuracion.  Django  usara  este  idioma  como  la 
traduccion  por  omision  - la  option  a seleccionarse  en  ultimo  termino  si  ningun  otro 
traductor  encuentra  una  traduccion. 

Si  todo  lo  que  deseas  hacer  es  ejecutar  Django  con  tu  idioma  nativo  y hay 
disponible  un  archivo  de  idioma  para  el  mismo,  simplemente  asigna  un  valor  a 
LANGUAGE_CODE. 

Si  deseas  permitir  que  cada  usuario  individual  especifique  el  idioma  que  ella  o el 
prefiere,  usa  LocaleMiddleware.  LocaleMiddleware  permite  la  selection  del  idioma 
basado  en  datos  incluidos  en  la  petition.  Personaliza  el  contenido  para  cada  usuario. 

Para  usar  LocaleMiddleware,  agrega  django.middleware.locale.LocaleMiddleware 
a tu  variable  de  configuracion  MIDDLEWARE_CLASSES.  Debido  a que  el  orden  de  los 
middlewares  es  relevante,  deberias  seguir  las  siguientes  guias: 

■ Asegurate  de  que  se  encuentre  entre  las  primeras  clases  middleware 
instaladas. 

■ Debe  estar  ubicado  despues  de  SessionMiddleware,  esto  es  debido  a que 
LocaleMiddleware  usa  datos  de  la  sesion. 

■ Si  usas  CacheMiddleware,  coloca  LocaleMiddleware  despues  de  este  (de  otra 
forma  los  usuarios  podrian  recibir  contenido  cacheado  del  locale 
equivocado). 

Por  ejemplo  tu  MIDDLEWARE_CLASSES  podria  verse  como  esta: 

MIDDLEWARE_CLASSES  = ( 

’django.contrib. sessions. middleware. SessionMiddleware’, 

'django.  middleware. locale.  LocaleMiddleware’, 

'django.  middleware. common. CommonMiddleware’, 

) 

LocaleMiddleware  intenta  determinar  la  preferencia  de  idioma  del  usuario 
siguiendo  el  siguiente  algoritmo: 

Primero,  busca  una  clave  djangolanguage  en  la  sesion  del  usuario  actual. 

■ Si  eso  falla,  busca  una  cookie  llamada  django  language. 

■ Si  eso  falla,  busca  la  cabecera  E1TTP  Accept-Language.  Esta  cabecera  es 
enviada  por  tu  navegador  y le  indica  al  servidor  que  idioma(s)  prefleres  en 
orden  de  prioridad.  Django  intenta  con  cada  idioma  que  aparezca  en  dicha 
cabecera  hasta  que  encuentra  uno  para  el  que  haya  disponible  una 
traduccion. 

■ Si  eso  falla,  usa  la  variable  de  configuracion  global  LANGUAGE_CODE. 

En  cada  uno  de  dichas  ubicaciones,  el  formato  esperado  para  la  preferencia  de 
idioma  es  el  formato  estandar,  como  una  cadena.  Por  ejemplo,  portugues  de  Brasil  es 
pt-br. 
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Si  un  idioma  base  esta  disponible  pero  el  sub-idioma  especificado  no,  Django 
usara  el  idioma  base.  Por  ejemplo,  si  un  usuario  especifica  de-at  (aleman  Austriaco) 
pero  Django  solo  tiene  disponible  de,  usara  de. 

Solo  pueden  seleccionarse  idiomas  que  se  encuentren  listados  en  la  variable  de 
configuracion  LANGUAGES.  Si  deseas  restringir  la  seleccion  de  idiomas  a un 
subconjunto  de  los  idiomas  provistos  (debido  a que  tu  aplicacion  no  incluye  todos 
esos  idiomas),  fija  tu  LANGUAGES  a una  lista  de  idiomas,  por  ejemplo: 

LANGUAGES  = ( 

(’de’,  _(’German’)), 

(’en*,  J’English’)), 

) 


Este  ejemplo  restringe  los  idiomas  que  se  encuentran  disponibles  para  su 
seleccion  automatica  a aleman  e ingles  (y  cualquier  sub-idioma,  como  de-ch  o en- 
us). 

Si  defines  un  LANGUAGES  personalizado  es  posible  marcar  los  idiomas  como 
cadenas  de  traduccion  - pero  usa  una  funcion  gettextO  “boba”,  no  la  que  se 
encuentra  en  django.utils.translation.  Nunca  debes  importar  django.utils.translation 
desde  el  archivo  de  configuracion  debido  a que  ese  modulo  a su  vez  depende  de  las 
variables  de  configuracion,  y eso  crearia  una  importation  circular. 

La  solution  es  usar  una  funcion  gettextO'  “boba”.  A continuation  un  archivo  de 
configuracion  de  ejemplo: 

ugettext  = lambda  s:  s 
LANGUAGES  = ( 

(’de’,  ugettext(’German’)), 

(’en’,  ugettext(’English’)), 

) 


Con  este  esquema,  django-admin.py  makemessages  todavia  sera  capaz  de 
encontrar  y marcar  dichas  cadenas  para  su  traduccion  pero  la  misma  no  ocurrira  en 
tiempo  de  ejecucion,  de  manera  que  tendras  que  recordar  envolver  los  idiomas  con  la 
verdadera  gettextO  en  cualquier  codigo  que  use  LANGUAGES  en  tiempo  de 
ejecucion. 

El  LocaleMiddleware  solo  puede  seleccionar  idiomas  para  los  cuales  exista  una 
traduccion  base  provista  por  Django.  Si  deseas  ofrecer  traducciones  para  tu 
aplicacion  que  no  se  encuentran  en  el  conjunto  de  traducciones  incluidas  en  el 
codigo  fuente  de  Django,  querras  proveer  al  menos  traducciones  basicas  para  ese 
idioma.  Por  ejemplo,  Django  usa  identificadores  de  mensajes  tecnicos  para  traducir 
formatos  de  fechas  y de  horas  - asi  que  necesitaras  al  menos  esas  traducciones  para 
que  el  sistema  funcione  correctamente. 

Un  buen  punto  de  partida  es  copiar  el  archivo  .po  de  ingles  y traducir  al  menos  los 
mensajes  tecnicos,  y quiza  tambien  los  mensajes  de  los  validadores. 

Los  identificadores  de  mensajes  tecnicos  son  facilmente  reconocibles;  estan 
completamente  en  mayusculas.  No  necesitas  traducir  los  identificadores  de  mensajes 
como  lo  haces  con  otros  mensajes;  en  cambio,  deber  proporcionar  la  variante  local 
correcta  del  valor  provisto  en  ingles.  Por  ejemplo,  con  DATETIME_FORMAT  (o 
DATE_FORMAT  o TIME_FORMAT),  este  seria  la  cadena  de  formato  que  deseas  usar 
en  tu  idioma.  El  formato  es  identico  al  de  la  cadena  de  formato  usado  por  la  etiqueta 
de  plantillas  now. 

Una  vez  que  el  LocaleMiddleware  ha  determinado  la  preferencia  del  usuario,  la 
deja  disponible  como  request.LANGUAGE_CODE  para  cada  objeto  petition.  Eres 
libre  de  leer  este  valor  en  tu  codigo  de  vista.  A continuation  un  ejemplo  simple: 
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def  hola_mundo(request): 

if  request. LANG UAGE_CODE  ==  ’de-at': 

return  HttpResponse("You  prefer  to  read  Austrian  German.") 

else: 

return  HttpResponse("You  prefer  to  read  another  language.") 

Nota  que  con  traduction  estatica  (en  otras  palabras  sin  middleware)  el  idioma 
esta  en  settings. LANGUAGE_CODE,  mientras  que  con  traduction  dinamica  (con 
middleware)  el  mismo  esta  en  request.LANGUAGE_CODE. 


Usando  traducciones  en  tus  propios  proyectos 


Django  busca  traducciones  siguiendo  el  siguiendo  algoritmo: 

■ Primero,  busca  un  directorio  locale  en  el  directorio  de  la  aplicacion 
correspondiente  a la  vista  que  se  esta  llamando.  Si  encuentra  una  traduction 
para  el  idioma  seleccionado,  la  misma  sera  instalada. 

■ A continuation,  busca  un  directorio  locale  en  el  directorio  del  proyecto.  Si 
encuentra  una  traduction,  la  misma  sera  instalada. 

■ Finalmente,  verifica  la  traduction  base  en  django/conf/locale. 

De  esta  forma,  puedes  escribir  aplicaciones  que  incluyan  sus  propias 
traducciones,  y puedes  reemplazar  traducciones  base  colocando  las  tuyas  propias  en 
la  ruta  de  tu  proyecto.  O puedes  simplemente  construir  un  proyecto  grande  a partir 
de  varias  aplicaciones  y poner  todas  las  traducciones  en  un  gran  archivo  de  mensajes. 
Es  tu  election. 


<j,Nota:  Si  estas  configurando  manualmente  la  variables  de  configuration, 
el  directorio  locale  en  el  directorio  del  proyecto  no  sera  examinado,  dado  que 
Django  pierde  la  capacidad  de  deducir  la  ubicacion  del  directorio  del 
proyecto.  (Django  normalmente  usa  la  ubicacion  del  archivo  de  configuration 
para  determinar  esto,  y en  el  caso  que  estes  conflgurado  manualmente  tus 
variables  de  configuration  dicho  archivo  no  existe). 


Todos  los  repositorios  de  archivos  de  mensajes  estan  estructurados  de  la  misma 
forma: 


■ $APPPATH  / locale  / <language>  / LC_MESSAGES  / dj  ango . (po  | mo) 

■ $PROJECTPATH  / locale  / <language>  / LC_MESSAGES  / dj  ango.  (po  |mo) 

■ Todas  las  rutas  listadas  en  LOCALE_PATHS  en  tu  archivo  de  configuration 
son  examinadas  en  el  orden  de  busqueda  de 
<language>/LC_MESSAGES/django.  (po|mo) 

■ $PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.  (po| 
mo) 
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Para  crear  archivos  de  mensajes,  usas  la  misma  herramienta  django-admin.py 
makemessages  que  usabas  con  los  archivos  de  mensajes  de  Django.  Solo  necesitas 
estar  en  la  ubicacion  adecuada  - en  el  directorio  en  el  cual  exista  ya  sea  el  directorio 
conf /locale  (en  el  caso  del  arbol  de  codigo  fuente)  o el  directorio  locale/  (en  el  caso  de 
mensajes  de  aplicacion  o de  proyecto).  Usas  tambien  la  misma  herramienta  django- 
admin.py  compilemessages  para  producir  los  archivos  binarios  django.mo  usados 
por  gettext. 

Tambien  puedes  ejecutar  django-admin.py  compilemessages 
settings=path.to. settings  Para  hacer  que  el  compilador  procese  todo  los  directorios  de 
tu  configuracion  LOCALE_PATHS. 

Los  archivos  de  mensajes  de  aplicaciones  son  un  poquito  complicados  a la  hora  de 
buscar  por  los  mismos  - necesitas  el  LocaleMiddleware.  Si  no  usas  el  middleware, 
solo  seran  procesados  los  archivos  de  mensajes  de  Django  y del  proyecto. 

Finalmente,  debes  dedicarle  tiempo  al  diseno  de  la  estructura  de  tus  archivos  de 
traduccion.  Si  tus  aplicaciones  necesitan  ser  enviadas  a otros  usuarios  y seran  usadas 
en  otros  proyectos,  posiblemente  quieras  usar  traducciones  especificas  a dichas 
aplicaciones.  Pero  el  usar  traducciones  especificas  a aplicaciones  y aplicaciones  en 
proyectos  podrian  producir  problemas  extranos  con  makemessages.py: 
makemessages  recorrera  todos  los  directorios  situados  por  debajo  de  la  ruta  actual  y 
de  esa  forma  podria  colocar  en  el  archivo  de  mensajes  del  proyecto  identificadores  de 
mensajes  que  ya  se  encuentran  en  los  archivos  de  mensajes  de  la  aplicacion. 

La  salida  mas  facil  de  este  problema  es  almacenar  las  aplicaciones  que  no  son 
partes  del  proyecto  (y  por  ende  poseen  sus  propias  traducciones)  fuera  del  arbol  del 
proyecto.  De  esa  forma  django-admin.py  makemessages  ejecutado  a nivel  proyecto 
solo  traducira  cadenas  que  estan  conectadas  a tu  proyecto  y no  cadenas  que  son 
distribuidas  en  forma  independiente. 


La  vista  de  redireccion  setjanguage 

Por  conveniencia,  Django  incluye  una  vista  dj ango. vie ws.il8n. setjanguage,  que  flja 
la  preferencia  de  idioma  de  un  usuario  y redirecciona  de  vuelta  a la  pagina  previa. 
Activa  esta  vista  agregando  la  siguiente  linea  a tu  URLconf: 

url(r’Ail8n/’,  include(’django.conf.urls.il8n’)), 

Observa  que  este  ejemplo  hace  que  la  vista  este  disponible  en  /il8n/setlang/. 

La  vista  espera  ser  llamada  via  el  metodo  POST,  con  un  parametro  language  incluido 
en  la  cadena  de  peticion.  Si  el  soporte  para  sesiones  esta  activo,  la  vista  guarda  la 
opcion  de  idioma  en  la  sesion  del  usuario.  En  caso  contrario,  guarda  el  idioma  en  una 
cookie  django  Janguage.  (El  nombre  puede  ser  cambiado  a traves  de  la  configuracion 
LANGUAGE_COOKIE_NAME.) 

Despues  de  haber  fijado  la  opcion  de  idioma  Django  redirecciona  al  usuario,  para 
eso  sigue  el  siguiente  algoritmo: 

■ Django  busca  un  parametro  next  en  los  datos  POST. 

■ Si  el  mismo  no  existe  o esta  vacio,  Django  intenta  la  URL  contenida  en  la 
cabecera  Referer. 

■ Si  la  misma  esta  vacia  - por  ejemplo,  si  el  navegador  de  un  usuario  suprime 
dicha  cabecera  entonces  el  usuario  sera  redireccionado  a / (la  raiz  del  sitio) 
como  ultimo  recurso. 
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Este  es  un  fragmento  de  codigo  de  plantilla  HTML  de  ejemplo: 

<form  action="/il8n/setlang/"  method="post"> 

<input  name="next"  type="hidden"  value="/next/page/"  /> 

<select  name="language"> 

{%  for  lang  in  LANGUAGES  %} 

<option  value="{{  lang.O  }}">{{  lang.l  }}</option> 

{%  endfor  %} 

</select> 

<input  type="submit"  value="Go"  /> 

</form> 

Traducciones  y JavaScript 

Agregar  traducciones  a JavaScript  plantea  algunos  problemas: 

■ El  codigo  JavaScript  no  tiene  acceso  a una  implementation  de  gettext. 

■ El  codigo  JavaScript  no  tiene  acceso  a los  archivos  .po  o .mo;  los  mismos 
necesitan  ser  enviados  desde  el  servidor. 

■ Los  catalogos  de  traduction  para  JavaScript  deben  ser  mantenidos  tan 
pequenos  como  sea  posible. 

Django  provee  una  solution  integrada  para  estos  problemas:  convierte  las 
traducciones  a JavaScript,  de  manera  que  puedas  11am ar  a gettext  y demas  desde 
JavaScript. 

La  vista  javascript_catalog 

La  solution  principal  a esos  problemas  es  la  vista  javascript_catalog,  que  genera  una 
biblioteca  de  codigo  JavaScript  con  funciones  que  emulan  la  interfaz  gettext  mas  un 
arreglo  de  cadenas  de  traduction.  Dichas  cadenas  de  traduction  se  toman  desde  la 
aplicacion,  el  proyecto  o el  nucleo  de  Django,  de  acuerdo  a lo  que  especiliques  ya  sea 
en  el  diccionario  info_dict  o en  la  URL. 

La  forma  de  usar  esto  es  asi: 

js_info_dict  = { 

’packages’:  (’your. app. package’,), 

} 

urlpatterns  [ 

url(r’Ajsil8n/$’,  ’django. views. i!8n.javascript_catalog’,  js  info  dict), 

] 


Cada  cadena  en  package  debe  seguir  la  sintaxis  de  paquetes  separados  por  puntos 
de  Python  (el  mismo  formato  que  las  cadenas  en  INSTALLED_APPS)  y deben  referirse 
a un  paquete  que  contenga  un  directorio  locale.  Si  se  especifican  multiples  paquetes, 
todos  esos  catalogos  son  fusionados  en  un  unico  catalogo.  Esto  es  util  si  usas 
JavaScript  que  usa  cadenas  de  diferentes  aplicaciones. 

Puedes  hacer  que  la  vista  sea  dinamica  colocando  los  paquetes  en  el  patron  de  la 
URL: 
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urlpatterns  = [ 

url(r'Ajsil8n/(?P<packages>\S+?)/$,  'django.views.il8n.javascript_catalog'), 

] 


Con  esto,  especificas  los  paquetes  como  una  lista  de  nombres  de  paquetes 
delimitados  por  un  simbolo  + en  la  URL.  Esto  es  especialmente  util  si  tus  paginas 
usan  codigo  de  diferentes  aplicaciones,  este  cambia  frecuentemente  y no  deseas 
tener  que  descargar  un  unico  gran  catalogo.  Como  una  medida  de  seguridad,  esos 
valores  pueden  solo  tomar  los  valores  django.conf  o cualquier  paquete  de  la  variable 
de  configuration  INSTALLED_APPS. 

Usando  el  catalogo  de  traducciones  JavaScript 


Para  usar  el  catalogo  simplemente  descarga  el  script  generado  dinamicamente  de  la 
siguiente  forma: 

<script  type- 'text/javascript"  src="/path/to/jsil8n/"x/script> 

Esta  es  la  forma  en  la  que  el  sitio  de  administration  obtiene  el  catalogo  de 
traducciones  desde  el  servidor.  Una  vez  que  se  ha  cargado  el  catalogo,  tu  codigo 
JavaScript  puede  usar  la  interfaz  estandar  gettext  para  acceder  al  mismo: 

document. write(gettext(’esto  sera  traducido’)); 

Hay  tambien  un  interfaz  de  ngettext: 

var  object_cnt  = 1 //  or  0,  or  2,  or  3,  ... 
s = ngettext(’literal  para  algun  caso  en  singular’, 
literal  para  casos  en  plural’,  object_cnt); 

E incluso,  una  funcion  de  interpolacion  de  cadenas: 
function  interpolate(fmt,  obj,  named); 

La  sintaxis  de  interpolacion  se  tomo  prestada  de  Python,  por  lo  que  la  funcion 
interpolate  soporta  tanto  la  interpolacion  por  nombre  y posicional. 

■ Interpolacion  posicional:  un  obj  que  contiene  un  arreglo  de  objetos 
cuyos  valores  de  sus  elementos  son  secuencialmente  interpolados  en  su 
correspondiente  marcador  de  position  fmt,  en  el  mismo  orden  en  que 
aparecen.  Por  ejemplo: 

fmts  = ngettext(’There  is  %s  object.  Remaining:  %s’, 

There  are  %s  objects.  Remaining:  %s\  11); 
s = interpolate(fmts,  [11,  20]); 

//  s is  ’There  are  11  objects.  Remaining:  20’ 

■ Interpolacion  por  nombre:  Este  modo  es  seleccionado  pasando 
opcionalmente  un  parametro  booleano  named  como  true.  El  obj  puede 
contener  un  objeto  JavaScript  o un  arreglo  asociado.  Por  ejemplo: 


d = { 

count:  10 
total:  50 
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}; 


fmts  = ngettext('Total:  %(total)s,  there  is  %(count)s  object', 

'there  are  %(count)s  of  a total  of  %(total)s  objects',  d. count); 
s = interpolate(fmts,  d,  true); 

Sin  embargo,  no  debes  exagerar  con  el  uso  de  la  interpolacion  de  cadenas  - esto 
sigue  siendo  JavaScript  asi  que  el  codigo  tendra  que  realizar  multiples  sustituciones 
de  expresiones  regulares.  Esto  no  es  tan  rapido  como  la  interpolacion  de  cadenas  en 
Python,  de  manera  que  deberias  reservarlo  para  los  casos  en  los  que  realmente  lo 
necesites  (por  ejemplo  en  combination  con  ngettext  para  generar  pluralizaciones  en 
forma  correcta) . 

Creando  catalogos  de  traducciones  JavaScript 

Los  catalogos  de  traducciones  se  crean  y actualizan  de  la  misma  manera  que  el  resto 
de  los  catalogos  de  traducciones  de  Django,  con  la  herramienta  django-admin.py 
makemessages.  La  unica  diferencia  es  que  es  necesario  que  proveas  un  parametro  -d 
djangojs,  de  la  siguiente  forma: 

django-admin.py  makemessages  -d  djangojs  -I  de 

Esto  crea  o actualiza  el  catalogo  de  traduction  para  JavaScript  para  aleman.  Luego 
de  haber  actualizado  catalogos,  solo  ejecuta  django-admin.py  compilemessages  de  la 
misma  manera  que  lo  haces  con  los  catalogos  de  traduction  normales  de  Django. 

Notas  para  usuarios  familiarizados  con  gettext 

Si  conoces  gettext  podrias  notar  las  siguientes  particularidades  en  la  forma  en  que 
Django  maneja  las  traducciones: 

■ El  dominio  de  las  cadenas  es  django  o djangojs.  El  dominio  de  cadenas  se 
usa  para  diferenciar  entre  diferentes  programas  que  almacenan  sus  datos 
en  una  biblioteca  comun  de  archivos  de  mensajes  (usualmente 
/usr/share/locale/).  EL  dominio  django  se  usa  para  cadenas  de  traduction 
de  Python  y plantillas  y se  carga  en  los  catalogos  de  traducciones  globales. 
El  dominio  djangojs  se  usa  solo  para  catalogos  de  traducciones  de 
JavaScript  para  asegurar  que  los  mismos  sean  tan  pequenos  como  sea 
posible. 

■ Django  solo  usa  gettext  y gettext_noop.  Esto  es  debido  a que  Django 
siempre  usa  internamente  cadenas  DEFAULT_CHARSET.  Usar  ugettext  no 
significaria  muchas  ventajas  ya  que  de  todas  formas  siempre  necesitaras 
producir  UTF-8. 

■ Django  no  usa  xgettext  en  forma  independiente.  Usa  envoltorios  Python 
alrededor  de  xgettext  y msgfmt.  Esto  es  mas  que  nada  por  conveniencia. 

gettext  en  Windows 

La  siguiente  section  es  unicamente  para  personas  que  necesitan  extraer  mensajes 
IDs  o compilar  archivos  de  mensajes  (.po)  en  Windows.  El  trabajo  de  traduction  en  si 
mismo,  solo  implica  editar  los  archivos  existentes  de  este  tipo,  excepto  si  quieres 
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crear  tus  propios  archivos  de  mensajes,  o si  deseas  compilar  o probar  cambios  en 
archivos  de  mensajes,  necesitaras  usar  las  utilidades  gettext. 

Descarga  los  siguientes  archivos  zip  de  los  servidores  de  GNOME  desde: 

(?)  http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/  o de  cualquiera 
de  los  espejos:  (§)  http://ftp.gnome.org/pub/GNOME/MIRRORS 

■ gettext-runtime-x.zip 

■ gettext-tools-x.zip 

Donde  x es  el  numero  de  version,  la  minima  requerida  es  la  0.15. 

Extrae  los  3 archivos  en  un  mismo  folder  (por  ejemplo:  C:\Archivos  de 
Programas\utilidades  gettext) 

Actualiza  las  rutas  del  sistema  (PATE1): 

■ Dirigete  al  Panel  de  Control  > Sistema  > Avanzados  > Variables  de  entorno 

■ En  la  lista  de  Variables  del  sistema  busca  Path,  da  clic  en  Editar 

■ Y agrega;  C:\Archivos  de  Programas\ utilidades  gettext\bin  al  final  del  valor  del 
campo  valor  de  la  variable. 

Puedes  usar  tambien  los  binarios  gettext  obtenidos  en  alguna  otra  parte,  usando 
la  version  larga  xgettext  —version  para  que  el  comando  trabaje  adecuadamente. 

No  intentes  usar  en  Django,  utilidades  de  traduccion  con  un  paquete  gettext  si  el 
comando  xgettext  —version  causa  errores  al  ejecutarse  en  una  ventana  de  una 
terminal  tal  como  “xgettext.exe  has  generated  errors  and  will  be  closed  by  Windows”. 
Algunos  binarios  de  la  serie  0.14.4  no  soportan  este  comando. 


<?,Que  sigue? 


El  capitulo  final se  enfoca  en  la  seguridad  - como  proteger  tu  sitio  y a tus  usuarios  de 
atacantes  maliciosos. 


CAPITULO  20 


Seguridad 


"Internet  puede  ser  un  lugar  aterrador" 

En  estos  tiempos,  los  papelones  de  seguridad  en  internet  con  alta  exposition 
publica  parecen  ser  cosa  de  todos  los  dras.  Hemos  visto  virus  propagarse  con  una 
velocidad  asombrosa,  ejercitos  de  computadoras  comprometidas  ser  empunadas 
como  armas,  una  interminable  carrera  armamentista  contra  los  spammers,  y 
muchos,  muchos  reportes  de  robos  de  identidad  de  sitios  Web  hackeados. 

Parte  de  las  tareas  de  un  desarrollador  Web  es  hacer  lo  que  este  en  sus  manos  para 
combatir  esas  fuerzas  de  la  oscuridad.  Todo  desarrollador  Web  necesita  considerar  la 
seguridad  como  un  aspecto  fundamental  de  la  programacion  Web. 
Desafortunadamente,  se  da  el  caso  de  que  implementar  la  seguridad  es  diffcil  - los 
atacantes  solo  necesitan  encontrar  una  unica  vulnerabilidad,  pero  los  defensores 
deben  proteger  todas  y cada  una. 

Django  intenta  mitigar  esta  dificultad.  Esta  disenado  para  protege  rte 
automaticamente  de  muchos  de  los  errores  de  seguridad  comunes  que  cometen  los 
nuevos  (e  incluso  los  experimentados)  desarrolladores  Web.  Aun  asr,  es  importante 
entender  de  que  se  tratan  dichos  problemas,  como  es  que  Django  te  protege,  y - esto 
es  lo  mas  importante  los  pasos  que  puedes  tomar  para  hacer  tu  codigo  aun  mas 
seguro. 

Antes,  sin  embargo,  una  importante  aclaracion:  No  es  nuestra  intention  presentar 
una  guia  definitiva  sobre  todos  los  exploits  de  seguridad  Web  conocidos,  y tampoco 
trataremos  de  explicar  cada  vulnerabilidad  en  una  forma  completa.  En  cambio, 
presentaremos  una  breve  sinopsis  de  problemas  de  seguridad  que  son  relevantes 
para  Django. 


El  tema  de  la  seguridad  en  la  Web 


Si  aprendes  solo  una  cosa  de  este  capitulo,  que  sea  esta: 

Nunca  — bajo  ninguna  circunstancia  — confies  en  datos  enviados  por  un  navegador. 

Nunca  sabes  quien  esta  del  otro  lado  de  esa  conexion  HTTP.  Podrfa  tratarse  de  uno 
de  tus  usuarios,  pero  de  igual  forma  podria  tratarse  de  un  vil  cracker  buscando  el  mas 
minimo  resquicio. 

Cualquier  dato  de  cualquier  naturaleza  que  arriba  desde  el  navegador  necesita  ser 
tratado  con  una  generosa  dosis  de  paranoia.  Esto  incluye  tanto  datos  que  se 
encuentran  “in  band”  (por  ejemplo  enviados  desde  formularios  Web)  como  “out  of 
band ” (por  ejemplo  cabeceras  HTTP,  cookies,  y otra  information  de  peticion).  Es 
trivial  falsificar  los  metadatos  de  la  peticion  que  los  navegadores  usualmente  agregan 
automaticamente. 
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Todas  las  vulnerabilidades  tratadas  en  este  capitulo  derivan  directamente  de 
confiar  en  datos  que  arriban  a traves  del  cable  y luego  fallar  a la  hora  de  limpiar  esos 
datos  antes  de  usarlos.  Debes  convertir  en  una  practica  general  el  preguntarte  “,>De 
donde  vienen  estos  datos?” 

Inyeccion  de  SQL 


La  inyeccion  de  SQL  es  un  exploit  cormin  en  el  cual  un  atacante  altera  los  parametros 
de  la  pagina  (tales  como  datos  de  GET/POST  o URLs)  para  insertar  fragmentos 
arbitrarios  de  SQL  que  una  aplicacion  Web  ingenua  ejecuta  directamente  en  su  base 
de  datos.  Es  probablemente  la  mas  peligrosa  y,  desafortunadamente  una  de  las  mas 
comunes  vulnerabilidad  existente. 

Esta  vulnerabilidad  se  presenta  mas  comunmente  cuando  se  esta  construyendo 
SQL  “a  mano”  a partir  de  datos  ingresados  por  el  usuario.  Por  ejemplo,  imaginemos 
que  se  escribe  una  funcion  para  obtener  una  lista  de  informacion  de  contacto  desde 
una  pagina  de  busqueda.  Para  prevenir  que  los  spammers  lean  todas  las  direcciones 
de  email  en  nuestro  sistema,  vamos  a exigir  al  usuario  que  escriba  el  nombre  de 
usuario  del  cual  quiere  conocer  sus  datos  antes  de  proveerle  la  direction  de  email 
respectiva: 

def  user_contacts(request): 

user  = request. GET[’username’] 

sql  = "SELECT  * FROM  user_contacts  WHERE  username  = ’%s’;"  % username 
# ejecuta  consultas  SQL  aqui... 


Nota:  En  este  ejemplo,  y en  todos  los  ejemplos  similares  del  tipo  “no  hagas  esto” 
que  siguen,  hemos  omitido  deliberadamente  la  mayor  parte  del  codigo  necesario 
para  hacer  que  el  mismo  realmente  funcione.  No  queremos  que  este  codigo  sirva,  si 
accidentalmente  alguien  lo  toma  fuera  de  contexto  y lo  usa. 


A pesar  de  que  a primera  vista  eso  no  parece  peligroso,  realmente  lo  es. 

Primero,  nuestro  intento  de  proteger  nuestra  lista  de  emails  completa  va  a fallar 
con  una  consulta  construida  en  forma  ingeniosa.  Pensemos  acerca  de  que  sucede  si 
un  atacante  escribe  “‘OR’  ‘a’=’a”  en  la  caja  de  busqueda.  En  ese  caso,  la  consulta  que 
la  interpolation  construira  sera: 

SELECT  * FROM  user_contacts  WHERE  username  = " OR  'a'  = 'a'; 

Debido  a que  hemos  permitido  SQL  sin  protection  en  la  string,  la  clausula  OR 
agregada  por  el  atacante  logra  que  se  retornen  todos  los  registros. 

Sin  embargo,  ese  es  el  menos  pavoroso  de  los  ataques.  Imaginemos  que 
sucederia  si  el  atacante  envia  DELETE  FROM  user_contacts  WHERE  ‘a’  = ‘a’”.  Nos 
encontrariamos  con  la  siguiente  consulta  completa: 

SELECT  * FROM  user_contacts  WHERE  username  = 

DELETE  FROM  user_contacts  WHERE  'a'  = ’a’; 

jOuch!  ^Donde  irfa  a parar  nuestra  lista  de  contactos? 
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La  solucion 

Aunque  este  problema  es  insidioso  y a veces  dificil  de  detectar  la  solucion  es  simple: 
nunca  confies  en  datos  provistos  por  el  usuario  y siempre  escapa  el  mismo  cuando  lo 
conviertes  en  SQL. 

La  API  de  base  de  datos  de  Django  hace  esto  por  ti.  Escapa  automaticamente  todos 
los  parametros  especiales  SQL,  de  acuerdo  a las  convenciones  de  uso  de  comillas  del 
servidor  de  base  de  datos  que  estes  usando  (por  ejemplo,  PostgreSQL  o MySQL). 

Por  ejemplo,  en  esta  llamada  a la  API: 

foo.get_list(bar exact-”  OR  1=1") 

Django  escapara  la  entrada  apropiadamente,  resultando  en  una  sentencia  como 
esta: 

SELECT  * FROM  too  WHERE  bar  = 'V  OR  1=1' 

Que  es  completamente  inocua. 

Esto  se  aplica  a la  totalidad  de  la  API  de  base  de  datos  de  Django,  con  un  par  de 
excepciones: 

El  argumento  where  del  metodo  extraO  (ver  Apendice  C).  Dicho  parametro  acepta, 
por  diseno,  SQL  crudo. 

Consultas  realizadas  “a  mano”  usando  la  API  de  base  de  datos  de  nivel  mas  bajo. 
En  tales  casos,  es  facil  mantenerse  protegido.  para  ello  evita  realizar  interpolation 
de  strings  y en  cambio  usa  parametros  asociados  ( bind  parameters).  Esto  es,  el 
ejemplo  con  el  que  comenzamos  esta  section  debe  ser  escrito  de  la  siguiente  manera: 

from  django.db  import  connection 

def  user_contacts(request): 

user  = request. GET[’username’] 

sql  = "SELECT  * FROM  user_contacts  WHERE  username  = %s;" 
cursor  = connection.  cursor() 
cursor. execute(sql,  [user]) 

# ...  haz  algo  cono  los  resultados 

El  metodo  de  bajo  nivel  execute  toma  un  string  SQL  con  marcadores  de  position 
%s  y automaticamente  escapa  e inserta  parametros  desde  la  lista  que  se  le  provee 
como  segundo  argumento.  Cuando  construyas  SQL  en  forma  manual  hazlo  siempre 
de  esta  manera. 

Desafortunadamente,  no  puedes  usar  parametros  asociados  en  todas  partes  en 
SQL;  no  son  permitidos  como  identiflcadores  (esto  es,  nombres  de  tablas  o 
columnas).  Asi  que,  si,  por  ejemplo,  necesitas  construir  dinamicamente  una  lista  de 
tablas  a partir  de  una  variable  enviada  mediante  POST,  necesitaras  escapar  ese 
nombre  en  tu  codigo.  Django  provee  una  funcion,  django.db. backend.quote_name, 
la  cual  escapara  el  identificador  de  acuerdo  al  esquema  de  uso  de  comillas  de  la  base 
de  datos  actual. 

Cross-Site  Scripting 

El  Cross-site  scripting  (XSS)  (Scripting  inter-sitio),  puede  encontrarse  en  aplicaciones 
Web  que  fallan  a la  hora  de  escapar  en  forma  correcta  contenido  provisto  por  el 
usuario  antes  de  renderizarlo  en  HTML.  Esto  le  permite  a un  atacante  insertar  HTML 
arbitrario  en  tu  pagina  Web,  usualmente  en  la  forma  de  etiquetas  <script>. 
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Los  atacantes  a menudo  usan  ataques  XSS  para  robar  information  de  cookies  y 
sesiones,  o para  enganar  usuarios  y lograr  que  proporcionen  information  privada  a la 
persona  equivocada  (tambien  conocido  como  phishing). 

Este  tipo  de  ataque  puede  tomar  diferentes  formas  y tiene  practicamente  infinitas 
permutaciones,  asi  que  solo  vamos  a analizar  un  ejemplo  tipico.  Consideremos  esta 
simple  vista  “Hola  mundo”: 

from  django.http  import  HttpResponse 

def  di_hola(request): 

nombre  = request.GET.get(’nombre’) 

return  HttpResponse('<hl>Hola,  %s!</hl>'  % nombre) 


Esta  vista  simplemente  lee  un  nombre  desde  un  parametro  GET  y pasa  dicho 
nombre  a la  plantilla.  Podriamos  escribir  una  plantilla  para  esta  vista  de  la  siguiente 
manera: 

<hl>Hola,  {{ nombre  }}!</hl> 

De  manera  que  si  accedieramos  a http://example.com/hola/7nametiacob,  la 
pagina  renderizada  contendrfa  lo  siguiente: 

<hl>Hola,  Jacob!</hl> 

Pero  atencion  - ^que  sucede  si  accedemos  a 
http://example.com/hello/?nombre=<i>Jacob</i>?  En  ese  caso  obtenemos  esto: 

<hl>Hola,  <i>Jacob</i>!</hl> 

Obviamente,  un  atacante  no  usara  algo  tan  inofensivo  como  una  etiquetas  <i>; 
podria  incluir  un  fragmento  completo  de  E1TML  que  se  apropiara  de  tu  pagina 
insertando  contenido  arbitrario.  Este  tipo  de  ataques  ha  sido  usado  para  enganar  a 
usuarios  e inducirlos  a introducir  datos  en  lo  que  parece  ser  el  sitio  Web  de  su  banco, 
pero  en  efecto  es  un  formulario  saboteado  via  XSS  que  envia  su  information  bancaria 
a un  atacante. 

El  problema  se  complica  aun  mas  si  almacenas  estos  datos  en  la  base  de  datos  y 
luego  la  visualizas  en  tu  sitio.  Por  ejemplo,  en  una  oportunidad  se  encontro  que 
MySpace  era  vulnerable  a un  ataque  XSS  de  esta  naturaleza.  Un  usuario  habia 
insertado  JavaScript  en  su  pagina  de  perfil,  dicho  codigo  lo  agregaba  a la  lista  de 
amigos  de  todos  los  usuarios  que  visitaran  su  pagina  de  perfil.  En  unos  pocos  dias 
llego  a tener  millones  de  amigos. 

Ahora,  esto  podria  sonar  relativamente  inofensivo,  pero  no  olvides  que  este 
atacante  habia  logrado  que  su  codigo  - no  el  codigo  de  MySpace  - se  ejecutara  en  tu 
computadora.  Esto  viola  la  conflanza  asumida  acerca  de  que  todo  el  codigo  ubicado 
en  MySpace  es  realmente  escrito  por  MySpace. 

MySpace  fue  muy  afortunado  de  que  este  codigo  malicioso  no  hiciera  cosas  como 
borrar  automaticamente  las  cuentas  de  los  usuarios  que  lo  ejecutaran,  o cambiar  sus 
contrasenas,  o inundar  el  sitio  con  spam,  o cualquiera  de  los  otros  escenarios  de 
pesadilla  que  esta  vulnerabilidad  hace  posibles. 

La  solucion 

La  solucion  es  simple:  siempre  escapa  todo  el  contenido  que  pudiera  haber  sido 
enviado  por  un  usuario,  antes  de  insertarlo  dentro  del  HTML. 
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Para  protegerte  contra  esto,  el  sistema  de  la  plantilla  de  Django  automaticamente 
escapa  todos  los  valores  de  las  variables.  Veamos  que  sucede  si  reescribimos  nuestro 
ejemplo  usando  el  sistema  de  plantillas: 

# views. py 

from  django. shortcuts  import  render 
def  di_hola(request): 

nombre  = request.GET.get('nombre',  'mundo') 
return  render(request,  'hola.html',  {'nombre':  nombre}) 

# hola.html 

<hl>Hola,  {{ nombre  }}!</hl> 

Con  esto  en  su  lugar  Django  automaticamente  escapa  los  valores  de  las  variables, 
en  este  caso  la  variable  nombre.  Sin  embargo  aun  podemos  manualmente  usar  un 
filtro  escape  en  la  plantilla: 

<hl>Hola,  {{ nombre|escape  }}!</hl> 

De  esta  manera  ya  no  seriamos  vulnerables.  Debes  usar  siempre  la  etiqueta 
escape  (o  algo  equivalente)  cuando  visualizas  en  tu  sitio  contenido  enviado  por  el 
usuario. 

En  el  capi'tulo  4 Lratamos  el  tema  del  auto-escape  y la  forma  de  desactivarlo.  Por  lo 
que  siempre  que  uses  esta  caracteristica,  asegurarte  de  activarlo.  Aun  si  Django 
incorpora  esta  caracteristica  debes  formarte  el  habito  de  preguntarte,  en  todo 
momento,  “^De  donde  provienen  estos  datos?”.  Ya  que  ninguna  solution  automatica 
protegera  tu  sitio  de  ataques  XSS  el  100%  del  tiempo. 

Cross-Site  Request  Forgery 

Los  ataques  mediante  cross-site  request  forgery  (CSRF)  (Falsification  de  peticiones 
inter-sitio)  suceden,  cuando  un  sitio  Web  malicioso  engana  a los  usuarios  y los 
induce  a visitar  una  URL  desde  un  sitio  ante  el  cual  ya  se  han  autenticado  - por  lo 
tanto  saca  provecho  de  su  condition  de  usuario  ya  autenticado. 

Django  incluye  herramientas  para  proteger  ante  este  tipo  de  ataques.  Tanto  el 
ataque  en  si  mismo  como  dichas  herramientas  son  tratados  con  gran  detalle  en  el 
capitulo  16. 

Session  Forging/Hijacking 

No  se  trata  de  un  ataque  especifico,  sino  una  clase  general  de  ataques  sobre  los  datos 
de  sesion  de  un  usuario.  Puede  tomar  diferentes  formas: 

• Un  ataque  del  tipo  man-in-the-middle,  en  el  cual  un  atacante  espia  datos 
de  sesion  mientras  estos  viajan  por  la  red  (cableada  o inalambrica). 

• Session  forging  (Falsification  de  sesion),  en  la  cual  un  atacante  usa  un 
identificador  de  sesion  (posiblemente  obtenido  mediante  un  ataque  man- 
in-the-middle)  para  simular  ser  otro  usuario. 

Un  ejemplo  de  los  dos  primeros  seria  una  atacante  en  una  cafeteria 
usando  la  red  inalambrica  del  lugar  para  capturar  una  cookie  de  sesion. 
Podria  usar  esa  cookie  para  hacerse  pasar  por  el  usuario  original. 
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• Un  ataque  de  falsification  de  cookies  en  el  cual  un  atacante  sobrescribe  los 
datos  almacenados  en  una  cookie  que  en  teoria  no  son  modificables.  El 
capitulo  14  explica  en  detalle  como  funcionan  las  cookies,  y uno  de  los 
puntos  salientes  es  que  es  trivial  para  los  navegadores  y usuarios 
maliciosos  el  cambiar  las  cookies  sin  tu  conocimiento. 

Existe  una  larga  historia  de  sitios  Web  que  han  almacenado  una  cookie  del 
tipo  IsLoggedIn=l  o aun  LoggedInAsUser=jacob.  Es  trivialmente  sencillo 
sacar  provecho  de  ese  tipo  de  cookies. 

En  un  nivel  aun  mas  sutil,  nunca  sera  una  buena  idea  confiar  en  nada  que 
se  almacene  en  cookies;  nunca  sabes  quien  puede  haber  estado 
manoseando  las  mismas. 

• Session  fixation  (fijacion  de  sesion),  en  la  cual  un  atacante  engana  a un 
usuario  y logra  asignar  un  nuevo  valor  o limpiar  el  valor  existente  del 
identificador  de  su  sesion. 

Por  ejemplo,  PE1P  permite  que  los  identificadores  de  sesion  se  pasen  en  la 
URL  (por  ejemplo, 

http://example.com/?PElPSESSID=fa90197ca25f6ab40bbl374c510d7a32). 
Un  atacante  que  logre  enganar  a un  usuario  para  que  haga  clic  en  un  link 
que  posea  un  identificador  de  sesion  lijo  causara  que  ese  usuario 
comience  a usar  esa  sesion. 

La  fijacion  de  sesion  se  ha  usado  en  ataques  de  phishing  para  enganar  a 
usuarios  e inducirlos  a ingresar  information  personal  en  una  cuenta  que 
esta  bajo  el  control  de  atacante.  Este  puede  luego  conectarse  al  sitio  con 
dicho  usuario  y obtener  datos. 

• Session  poisoning  (envenenamiento  de  sesion),  en  el  cual  in  atacante 
inyecta  datos  potencialmente  peligrosos  en  la  sesion  de  un  usuario  - 
usualmente  a traves  de  un  formulario  que  el  usuario  envia  con  datos  de  su 
sesion. 

Un  ejemplo  canonico  es  un  sitio  que  almacena  un  valor  de  preferencia 
simple  (como  el  color  de  fondo  de  una  pagina)  en  una  cookie.  Un  atacante 
podria  enganar  a un  usuario  e inducirlo  a hacer  clic  en  un  link  que  envia 
un  “color”  que  en  realidad  contiene  un  ataque  XSS;  si  dicho  color  no  esta 
siendo  escapado,  el  usuario  podria  insertar  nuevamente  codigo  malicioso 
en  el  entorno  del  usuario. 


La  solucion 

Existe  un  numero  de  principios  generales  que  pueden  protegerte  de  estos  ataques: 

■ Nunca  permitas  que  exista  information  sobre  sesiones  contenida  en  las 
URLs. 

o El  framework  de  sesiones  de  Django  (ver  capitulo  14)  simplemente 
no  permite  que  las  URLs  contengan  sesiones. 
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■ No  almacenes  datos  en  cookies  en  forma  directa;  en  cambio,  almacena  un 
identificador  de  sesion  que  este  relacionado  a datos  de  sesion 
almacenados  en  el  back-end. 

■ Si  usas  el  framework  de  sesiones  incluido  en  Django  (o  sea 
request.session),  eso  es  manejado  en  forma  automatica.  La  unica  cookie 
que  usa  el  framework  de  sesiones  es  un  identificador  de  sesion;  todos  los 
datos  de  la  sesiones  se  almacenan  en  la  base  de  datos. 

■ Recuerda  escapar  los  datos  de  la  sesion  si  los  visualizas  en  la  plantilla. 
Revisa  la  section  previa  sobre  XSS  y recuerda  que  esto  se  aplica  a cualquier 
contenido  creado  por  el  usuario  asi  como  a cualquier  dato  enviado  por  el 
navegador.  Debes  considerar  la  information  de  sesiones  como  datos 
creados  por  el  usuario. 

Previene  la  falsification  de  de  identificadores  de  sesion  por  parte  de  un  atacante 
siempre  que  sea  posible. 

A pesar  de  que  es  practicamente  imposible  detectar  a alguien  que  se  ha  apropiado 
de  un  identificador  de  sesion,  Django  incluye  protection  contra  un  ataque  de 
sesiones  de  fuerza  bruta. 

Los  identificadores  de  sesion  se  almacenan  como  hashes  (en  vez  de  numeros 
secuenciales)  lo  que  previene  un  ataque  por  fuerza  bruta,  y un  usuario  siempre 
obtendra  un  nuevo  identificador  de  sesion  si  intenta  usar  uno  no  existente,  lo  que 
previene  la  session  fixation. 

Nota  que  ninguno  de  estos  principios  y herramientas  previene  ante  ataques  man- 
in-the-middle.  Dichos  tipos  de  ataques  son  practicamente  imposibles  de  detectar.  Si 
tu  sitio  permite  que  usuarios  identificados  visualicen  algun  tipo  de  datos  importantes 
debes,  siempre,  publicar  dicho  sitio  via  HTTPS.  Adicionalmente,  si  tienes  un  sitio  con 
SSL,  debes  asignar  a la  variable  de  configuration  SESSION_COOKIE_SECURE  el  valor 
True;  esto  hara  que  Django  envie  las  cookies  de  sesion  via  HTTPS. 

Inyeccion  de  cabeceras  de  email 


La  hermana  menos  conocida  de  la  inyeccion  de  SQL,  la  inyeccion  de  cabeceras  de 
email,  toma  control  de  formularios  Web  que  envian  emails.  Un  atacante  puede  usar 
esta  tecnica  para  enviar  spam  mediante  tu  servidor  de  email.  Cualquier  formulario 
que  construya  cabeceras  de  email  a partir  de  datos  de  un  formulario  Web  es 
vulnerable  a este  tipo  de  ataque. 

Analicemos  el  formulario  de  contacto  canonico  que  puede  encontrarse  en 
muchos  sitios.  Usualmente  el  mismo  envia  un  mensaje  a una  direction  de  email  fija 
y,  por  lo  tanto,  a primera  vista  no  parece  ser  vulnerable  a abusos  de  spam. 

Sin  embargo,  muchos  de  esos  formularios  permiten  tambien  que  los  usuarios 
escriban  su  propio  asunto  para  el  email  (en  conjunto  con  una  direction  “de”,  el 
cuerpo  del  mensaje  y a veces  algunos  otros  campos).  Este  campo  asunto  es  usado 
para  construir  la  cabecera  “subject”  del  mensaje  de  email. 

Si  dicha  cabecera  no  es  escapada  cuando  se  construye  el  mensaje  de  email,  un 
atacante  podria  enviar  algo  como  "hello\ncc:spamvictim@example.com"  (donde 
"\n"  es  un  caracter  de  salto  de  linea).  Eso  haria  que  las  cabeceras  de  email  fueran: 

To:  hardcoded@example.com 

Subject:  hello 

cc:  spamvictim@example.com 
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Como  en  la  inyeccion  de  SQL,  si  confiamos  en  la  linea  de  asunto  enviada  por  el 
usuario,  estaremos  permitiendole  construir  un  conjunto  malicioso  de  cabeceras,  y 
podra  usar  nuestro  formulario  de  contacto  para  enviar  spam. 


La  solucion 


Podemos  prevenir  este  ataque  de  la  misma  manera  en  la  que  prevenimos  la  inyeccion 
de  SQL:  escapando  o veriflcando  siempre  el  contenido  enviado  por  el  usuario. 

Las  funciones  de  mail  incluidas  en  Django  (en  django.core.mail)  simplemente  no 
permiten  saltos  de  linea  en  ninguno  de  los  campos  usados  para  construir  cabeceras 
(las  direcciones  de  y para,  mas  el  asunto).  Si  intentas  usar 
django.core.mail.send_mail  con  un  asunto  que  contenga  saltos  de  linea,  Django 
arrojara  una  exception  BadHeaderError. 

Si  no  usas  las  funciones  de  email  de  Django  para  enviar  email,  necesitaras 
asegurarte  de  que  los  saltos  de  linea  en  las  cabeceras  o causan  un  error  o son 
eliminados.  Podrias  querer  examinar  la  clase  SafeMIMEText  en  django.core.mail  para 
ver  como  implementa  esto  Django. 

Directorio  Transversal 

Directorio  Transversal se  trata  de  otro  ataque  del  tipo  inyeccion,  en  el  cual  un  usuario 
malicioso  subvierte  codigo  de  manejo  de  sistema  de  archivos  para  que  lea  y/o  escriba 
archivos  a los  cuales  el  servidor  Web  no  deberia  tener  acceso. 

Un  ejemplo  podria  ser  una  vista  que  lee  archivos  desde  el  disco  sin  limpiar 
cuidadosamente  el  nombre  de  archivo: 

def  dump_file(request): 

filename  = request.  GET["filename"] 
filename  = os.path.join(BASE_PATH,  filename) 
content  = oper  (filename). read() 

# ... 

A pesar  que  parece  que  la  vista  restringe  el  acceso  a archivos  que  se  encuentren 
mas  alia  que  BASE_PATH  (usando  os.path.join),  si  el  atacante  envia  un  filename  que 
contenga  ..  (esto  es,  dos  puntos,  una  notation  corta  para  “el  directorio  padre”), 
podria  acceder  a archivos  que  se  encuentren  “mas  arriba”  que  BASE_PATH.  De  alii  en 
mas  es  solo  una  cuestion  de  tiempo  el  hecho  que  descubra  el  numero  correcto  de 
puntos  para  acceder  exitosamente,  por  ejemplo  a etc /passwd. 

Todo  aquello  que  lea  archivos  sin  el  escapado  adecuado  es  vulnerable  a este 
problema.  Las  vistas  que  escriben  archivos  son  igual  de  vulnerables,  pero  las 
consecuencias  son  doblemente  calamitosas. 

Otra  permutation  de  este  problema  yace  en  codigo  que  carga  modulos 
dinamicamente  a partir  de  la  URL  u otra  information  de  la  petition.  Un  muy  publico 
ejemplo  se  presento  en  el  mundo  de  Ruby  on  Rails.  Con  anterioridad  a mediados  del 
2006,  Rails  usaba  URLs  como  http://example.eom/person/poke/l  directamente  para 
cargar  modulos  e invocar  metodos.  El  resultado  fue  que  una  URL  cuidadosamente 
construida  podia  cargar  automaticamente  codigo  arbitrario,  jincluso  un  script  de 
reset  de  base  de  datos! 


La  solucion 


388  CAPITULO  20  HSEGURIDAD 


Si  tu  codigo  necesita  alguna  vez  leer  o escribir  archivos  a partir  de  datos  ingresados 
por  el  usuario,  necesitas  limpiar  muy  cuidadosamente  la  ruta  solicitada  para 
asegurarte  que  un  atacante  no  pueda  escapar  del  directorio  base  mas  alia  del  cual 
estas  restringiendo  el  acceso. 

/Nunca  debes  escribir  codigo  que  pueda  leer  cualquier  area  del  disco!  Un  buen 
ejemplo  de  como  hacer  este  escapado  yace  en  la  vista  de  publication  de  contenidos 
estaticos  (en  django .view. static). 

Este  es  el  codigo  relevante: 

import  os 
import  posixpath 

# ... 

path  = posixpath. normpath(urllib.unquote(path)) 
newpath  = ” 
for  part  in  path.split(V’): 
if  not  part: 

# strip  empty  path  components 

continue 

drive,  part  = os.path.splitdrive(part) 
head,  part  = os.path.split(part) 
if  part  in  (os.curdir,  os.pardir): 

# strip  and  in  path 

continue 

newpath  = os.path.join(newpath,  part).replace(’\Y,  7’) 


Django  no  lee  archivos  (a  menos  que  uses  la  funcion  static. serve,  pero  en  ese  caso 
esta  protegida  por  el  codigo  recien  mostrado),  asi  que  esta  vulnerabilidad  no  afecta 
demasiado  el  codigo  del  nucleo. 

Adicionalmente,  el  uso  de  la  abstraction  de  URLconf  significa  que  Django  solo 
cargara  codigo  que  le  hayas  indicado  explicitamente  que  cargue.  No  existe  manera  de 
crear  una  URL  que  cause  que  Django  cargue  algo  no  mencionado  en  una  URLconf. 

Exposicion  de  mensajes  de  error 


Mientras  se  desarrolla,  tener  la  posibilidad  de  ver  tracebacks  y errores  en  vivo  en  tu 
navegador  es  extremadamente  util.  Django  posee  mensajes  de  depuration  “vistosos” 
e informativos  especificamente  para  hacer  la  tarea  de  depuration  mas  facil. 

Sin  embargo,  si  esos  errores  son  visualizados  una  vez  que  el  sitio  pasa  a 
production,  pueden  revelar  aspectos  de  tu  codigo  o configuration  que  podrian  ser  de 
utilidad  a un  atacante. 

Es  mas,  los  errores  y tracebacks  no  son  para  nada  utiles  para  los  usuarios  finales. 
La  filosofia  de  Django  es  que  los  visitantes  al  sitio  nunca  deben  ver  mensajes  de  error 
relacionados  a una  aplicacion.  Si  tu  codigo  genera  una  exception  no  tratada,  un 
visitante  al  sitio  no  deberia  ver  un  traceback  completo  - ni  ninguna  pista  de 
fragmentos  de  codigo  o mensajes  de  error  (destinados  a programadores)  de  Python. 
En  cambio,  el  visitante  deberia  ver  un  amistoso  mensaje  “Esta  pagina  no  esta 
disponible”. 
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Naturalmente,  por  supuesto,  los  desarrolladores  necesitan  ver  tracebacks  para 
depurar  problemas  en  su  codigo.  Asi  que  el  framework  deberfa  ocultar  todos  los 
mensajes  de  error  al  publico  pero  deberia  mostrarlos  a los  desarrolladores  del  sitio. 

La  solucion 

Como  se  mostro  en  el  capitulo  12,  Django  contiene  un  sencillo  control  que  gobierna 
la  visualizacion  de  esos  mensajes  de  error.  Si  se  fija  la  variable  de  configuracion 
DEBUG  al  valor  True,  los  mensajes  de  error  seran  visualizados  en  el  navegador.  De 
otra  forma,  Django  retornara  un  mensaje  HTTP  500  (“Error  interno  del  servidor”)  y 
renderizara  una  plantilla  de  error  provista  por  ti.  Esta  plantilla  de  error  tiene  el 
nombre  500.html  y debe  estar  situada  en  la  raiz  de  uno  de  tus  directorios  de 
plantillas. 

Dado  que  los  desarrolladores  aun  necesitan  ver  los  errores  que  se  generan  en  un 
sitio  en  produccion,  todos  los  errores  que  se  manejen  de  esta  manera  dispararan  el 
envio  de  un  email  con  el  traceback  completo  a las  direcciones  de  correo  configuradas 
en  la  variable  ADMINS. 

Los  usuarios  que  implementen  en  conjunto  con  Apache  y wsgLpython  deben 
tambien  asegurarse  que  tienen  PythonDebug  Off  en  sus  archivos  de  configuracion  de 
Apache;  esto  suprimira  cualquier  error  que  pudiera  ocurrir  aun  antes  de  que  Django 
se  haya  cargado. 


Unas  palabras  finales  sobre  la  seguridad 

Esperamos  que  esta  pequena  exposicion  sobre  problemas  de  seguridad  no  sea 
demasiado  intimidante.  Es  cierto  que  la  Web  puede  ser  un  mundo  salvaje  y confuso, 
pero  con  un  poco  de  prevision  puedes  tener  un  sitio  Web  seguro. 

Ten  en  mente  que  la  seguridad  Web  es  un  campo  en  constante  cambio;  si  estas 
leyendo  la  version  en  papel  de  este  libro,  asegurate  de  consultar  recursos  sobre 
seguridad  mas  actuates  en  busqueda  de  nuevas  vulnerabilidades  que  pudieran  haber 
sido  descubiertas  recientemente.  En  efecto,  siempre  es  una  buena  idea  dedicar  algun 
tiempo  semanalmente  o mensualmente  a investigar  y mantenerte  actualizado  acerca 
del  estado  de  la  seguridad  de  aplicaciones  Web.  Es  una  pequena  inversion  a realizar, 
pero  la  proteccion  que  obtendras  para  ti  y tus  usuarios  no  tiene  precio. 

<?,Que  sigue? 

Has  alcanzado  el  final  de  nuestro  programa  regular.  Los  siguientes  apendices 
contienen  material  de  referencia  que  puedes  necesitar  a medida  que  trabajes  sobre 
tus  proyectos  Django 

Te  deseamos  la  mejor  de  las  suertes  en  la  puesta  en  marcha  de  tu  sitio  Django,  ya 
sea  un  pequeno  juguete  para  ti  y tus  amigos  o el  proximo  gran  invento  de  internet  ©. 


PARTE4 


Apendice 


APENDICE  A 


Referenda  de  la  definicion  de 

modelos 


El  capltulo  5 explica  lo  basico  sobre  la  defi niciori  de  modelos,  y lo  utilizamos  a lo 
largo  del  libro,  sin  embargo  existe  un  enorme  rango  de  opciones  disponibles  que  no 
se  han  cubierto.  Este  apendice  explica  toda  option  disponible  en  la  definicion  de 
modelos. 

A pesar  de  que  estas  APIs  se  consideran  muy  estables,  los  desarrolladores  de 
Django  agregan  en  forma  consistente  y constante  nuevos  atajos  y conveniencias  a la 
definicion  de  modelos,  por  lo  que  es  buena  idea  comprobar  siempre  la 
documentation  mas  reciente  en  linea,  disponible  en  la  pagina  del  proyecto: 

® http://www.djangoproject.com/documentation/ 


Campos 

Un  campo  es  una  clase  abstracta  que  representa  una  columna  de  una  tab  la  de  una 
base  de  datos.  Django  usa  campos  o fields  para  crear  las  tablas  de  la  base  de  datos. 

La  parte  mas  importante  de  un  modelo  - y la  unica  parte  requerida  de  un  modelo 
es  la  lista  de  campos  de  la  base  de  datos  que  la  definen. 

Restricciones  en  el  nombre  de  los  campos 

Django  pone  solo  dos  restricciones  en  el  nombre  de  los  campos: 

• Un  nombre  de  campo  no  puede  ser  una  palabra  reservada  de  Python,  porque 
eso  ocasio naria  un  error  de  sintaxis  en  Python,  por  ejemplo: 

class  Ejemplo(models. Model): 

pass  = models. IntegerFieldQ  #j  'pass'  es  una  palabra  reservada  en  Python! 

• Un  nombre  de  campo  no  puede  contener  dos  o mas  guiones  bajos 
consecutivos,  debido  a la  forma  en  que  trabaja  la  sintaxis  de  las  consultas  de 
busquedas  de  Django,  por  ejemplo: 

class  Ejemplo(models. Model): 

too bar  = models. IntegerFieldQ  # 'too bar'  tiene  dos  guiones  bajos! 


Estas  limitaciones  se  pueden  manejar  sin  mayores  problemas,  dado  que  el 
nombre  del  campo  no  necesariamente  tiene  que  coincidir  con  el  nombre  de  la 
columna  en  la  base  de  datos.  Ver  “db_column”,  mas  abajo. 
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Las  palabras  reservadas  de  SQL,  como  join,  where,  o select,  son  permitidas  como 
nombres  de  campo,  dado  que  Django  “escapa”  todos  los  nombres  de  tabla  y columna 
de  la  base  de  datos  en  cada  consulta  SQL  subyacente.  Utiliza  la  sintaxis  de  “comillas” 
del  motor  de  base  de  datos  particular. 

Cada  campo  en  tu  modelo  debe  ser  una  instancia  de  la  clase  de  campo 
apropiada.  Django  usa  los  tipos  de  clase  Field  para  determinar  algunas  cosas: 

El  tipo  de  columna  de  la  base  de  datos  (ej.:  INTEGER,  VARCHAR). 

El  widget  a usar  en  la  interfaz  de  administracion  de  Django,  si  vas  a usarla  (ej., 
<inputtype="text">,  <select>). 

Los  requerimientos  minimos  de  validation,  que  se  usan  en  la  interfaz  de 
administracion  de  Django. 

A continuation,  una  lista  completa  de  las  clases  de  campo,  ordenadas 
alfabeticamente.  Los  campos  de  relation  (ForeignKey,  etc.)  se  tratan  en  la  siguiente 
section. 

AutoField 

Un  IntegerField  que  se  incrementa  automaticamente  de  acuerdo  con  los  IDs 
disponibles.  Normalmente  no  necesitaras  utilizarlos  directamente;  se  agrega  un 
campo  de  clave  primaria  automaticamente  a tu  modelo  si  no  especificas  una  clave 
primaria. 

BigintegerField 

Un  campo  para  almacenar  numeros  enteros  de  64  bits,  es  parecido  a un  campo 
IntegerField  excepto  que  garantiza  ajustar  numeros  de  9223372036854775808  a 
9223372036854775807. 

BinaryField 

Un  campo  que  almacena  datos  binarios.  Unicamente  soporta  la  asignacion  de  bytes. 
Ten  en  cuenta  que  este  campo  tiene  funcionalidades  limitadas.  Por  ejemplo  no  es 
posible  filtrar  un  queryset  en  un  valor  de  un  campo  BinaryField. 

BooleanField 

Un  campo  Verdadero/Falso. 
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Un  campo  booleano  en  MySQL  es  almacenado  en  una  columna  TINYINT  con  un 
valor  de  0 o 1 (la  mayoria  de  las  bases  de  datos  tienen  una  apropiada  instancia  de  tipo 
BOLEAN.)  Por  lo  que  en  MySQL  unicamente  cuando  se  recupera  un  valor 
almacenado  BooleanField  de  la  base  de  datos,  este  tiene  un  valor  de  1 o 0,  en  lugar  de 
True  o False.  Normalmente  esto  no  deberia  ser  un  problema,  ya  que  Python  garantiza 
que  1 ==  True  y 0 ==  False.  Simplemente  se  cuidadoso  si  escribes  algo  como:  obj  is 
True  cuando  obj  es  el  valor  de  un  atributo  boleano  de  un  modelo.  Si  el  modelo  fue 
construido  usando  el  backend  mysql,  las  pruebas  “is”  fallaran.  Es  mejor  usar  una 
pruebausando  “==”  en  casos  como  estos. 

CharField 

Un  campo  string,  para  cadenas  cortas  o largas.  Para  grandes  cantidades  de  texto,  usa 
TextField. 
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CharField  requiere  un  argumento  extra,  maxjength,  que  es  la  longitud  maxima  (en 
caracteres)  del  campo.  Esta  longitud  maxima  es  reforzada  a nivel  de  la  base  de  datos  y 
en  la  validation  de  Django. 

CommaSeparatedlntegerField 

Un  campo  de  enteros  separados  por  comas.  Igual  que  en  CharField,  se  requiere  el 
argumento  maxjength. 


DateField 

Un  campo  de  fecha.  DateField  tiene  algunos  argumentos  opcionales  extra,  como  se 
muestra  en  la  Tab  la  A- 1. 


Argumento 

Descripcion 

auto_now 

Asigna  automaticamente  al  campo  un  valor  igual  al  momento  en 
que  se  guarda  el  objeto.  Es  util  para  las  marcas  de  tiempo  “ultima 
modification”.  Observar  que  siempre  se  usa  la  fecha  actual;  no  es  un 
valor  por  omision  que  se  pueda  sobrescribir. 

auto_now_add 

Asigna  automaticamente  al  campo  un  valor  igual  al  momento  en 
que  se  crea  el  objeto.  Es  util  para  la  creation  de  marcas  de  tiempo. 
Observar  que  siempre  se  usa  la  fecha  actual;  no  es  un  valor  por 
omision  que  se  pueda  sobreescribir. 

Tabla  Al:  Argumentos  opcionales  extra  de  DateField 

DateTimeField 

Un  campo  de  fecha  y hora.  Tiene  las  mismas  opciones  extra  que  DateField. 

DecimalField 

Un  numero  decimal  de  precision-fija,  representado  en  Python  por  una  instancia  de 
decimal.  Decimal.  Requiere  de  dos  argumentos: 

Argumento 

Descripcion 

max_digits 

Fa  cantidad  maxima  de  dlgitos  permitidos  en  el  numero. 

decimal_places 

Fa  cantidad  de  posiciones  decimales  a almacenar  con  el  numero. 

Tabla  A2:  Argumentos  opcionales  extra  de  DateField 

Por  ejemplo,  para  almacenar  numeros  hasta  999  con  una  resolucion  de  dos 
decimales,  usa: 

models. DecimalField(...,  max_digits=5,  decimal_places=2) 

Y para  almacenar  numeros  hasta  aproximadamente  mil  millones  con  una 
resolucion  de  diez  dlgitos  decimales,  usa: 
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models. DecimalField(...,  max_digits=19,  decimal_places=10) 

Cuando  asignes  a DecimalField,  utiliza  cualquiera  de  los  objetos  decimal.Decimal 
o una  cadena  - no  un  numero  de  punto  flotante  Python. 

EmailField 

Un  CharField  que  chequea  que  el  valor  sea  una  direction  de  email  valida.  No  acepta 
maxjength;  max_length  se  establece  automaticamente  en  254. 


FileField 

Un  campo  para  subir  archivos. 

Nota:  Los  argumentos  primary_key  y unique,  no  estan  soportados,  si  los  usas  se 
lanzara  un  error  del  tipo:  TypeError 


Requiere  de  dos  argumentos  opcionales: 

upload_to\  La  ruta  del  sistema  de  archivos  local  que  se  agregara  a la 
configuration  de  MEDIA_ROOT  para  determinar  el  valor  de  el  atributo 
django.core.files.File.url. 

La  ruta  puede  contener  el  “formato  strftime" , (consulta  la  documentation  de 
Python  para  obtener  ayuda  sobre  el  modulo  estandar  time)  el  cual  se  usa  para 
remplazar  la  fecha/tiempo  de  el  archivo  a subir  (de  modo  que  los  ficheros  subidos  no 
llenen  el  directorio  dado.) 

Tambien  puede  contener  un  llamable,  tal  como  una  funcion,  la  cual  debe  ser 
llamada  para  obtener  la  ruta  a la  cual  subir  los  archivos,  incluyendo  el  nombre  del 
archivo.  Este  llamable  debe  permitir  aceptar  dos  argumentos  y devolver  la  ruta  estilo 
tipo  Unix  (con  barras  inclinadas)  para  pasarlas  a el  sistema  de  almacenamiento.  Los 
dos  argumentos  que  puedes  pasarle  son: 


Argumento  Description 


instance  Una  instancia  de  un  modelo  donde  este  deflnido  el  campo  FileField. 

Especiflcamente,  esta  es  la  instancia  en  particular  en  donde  el  fichero 
actual  esta  adjunto.  En  la  mayoria  de  los  casos,  este  objeto  no  habra 
sido  guardado  en  la  base  de  datos  todavia,  asi  que  si  utilizas  por  defecto 
AutoField,  puede  ser  que  todavia  no  tenga  un  valor  para  el  campo  de  la 
clave  primaria. 

filename  El  nombre  del  archivo  que  fue  originalmente  dado  al  archivo.  Esto 
puede  o no  ser  tornado  en  consideration,  al  determinar  la  ruta  final  del 
destino. 


Tabla  A3:  Argumentos  opcionales  de  FileField 


storage:  Un  objeto  para  almacenamiento,  el  cual  maneja  el  almacenamiento  y 
recuperation  de  los  archivos. 
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El  widget  predeterminado  para  este  campo  es  un  a ClearableFilelnput. 

El  uso  de  un  campo  FileField  o un  ImageField  en  un  modelo  requiere  algunos 
pasos: 

1.  En  el  archivo  de  configuration  (settings.py),  es  necesario  definir 
MEDIA_ROOT  con  la  ruta  completa  al  directorio  donde  quieras  que  Django 
almacene  los  archivos  subidos.  (Para  mayor  rendimiento,  estos  archivos  no  se 
almacenan  en  la  base  de  datos.)  Define  MEDIA_URL  con  la  URL  publica  base 
de  ese  directorio.  Asegurate  de  que  la  cuenta  del  usuario  del  servidor  web 
tenga  permiso  de  escritura  en  este  directorio. 

2.  Agregar  el  FileField  o ImageField  al  modelo,  asegurate  de  definir  la  option 
upload_to  para  decide  a Django  a cual  subdirectorio  de  MEDIA_ROOT  debe 
subir  los  archivos. 

3.  Todo  lo  que  se  va  a almacenar  en  la  base  de  datos  es  la  ruta  al  archivo  (relativa 
a MEDIA_ROOT).  Seguramente  preferiras  usar  la  facilidad  de  la  funcion  url 
provista  por  Django.  Por  ejemplo,  si  tu  campo  "ImageField"  se  llama  portada, 
puedes  obtener  la  URL  absoluta  a la  imagen  en  un  plantilla  usando: 

{{  object. portada. url }} 

Por  ejemplo,  digamos  que  tu  MEDIA_ROOT  es  '/home/media',  y upload_to  es 
'photos/%Y/%m/%d'.  La  parte  '%Y/%m/%d'  de  upload_to  esta  en  el  formato 
strftime;  '%Y'  es  el  ano  en  cuatro  digitos,  '%m'  es  el  mes  en  dos  digitos,  y '%d'  es  el  dia 
en  dos  digitos.  Si  subes  un  archivo  el  15  de  enero  de  2007,  sera  guardado  en 
/home/media/photos/2007/01/15. 

Si  quieres  recuperar  el  nombre  en  disco  del  archivo  subido,  o una  URL  que  se  refiera 
a ese  archivo,  o el  tamano  del  archivo,  puedes  referirte  al  archivo  mediante  sus 
atributos  name,  url  y size. 

Cualquiera  que  sea  la  forma  en  que  manejes  los  archivos  subidos,  tienes  que 
prestar  mucha  atencion  a donde  los  estas  subiendo  y que  tipo  de  archivos  son,  para 
evitar  huecos  en  la  seguridad.  Valida  todos  los  archivos  subidos  para  asegurarte  que 
esos  archivos  son  lo  que  piensas  que  son.  Por  ejemplo,  si  dejas  que  cualquiera  suba 
archivos  ciegamente,  sin  validation,  a un  directorio  que  esta  dentro  de  la  raiz  de 
documentos  {document root)  de  tu  servidor  web,  alguien  podria  subir  un  script  CGI  o 
PHP  y ejecutarlo  visitando  su  URL  en  tu  sitio.  jNo  permitas  que  pase! 

Por  defecto  las  instancias  de  FileField  son  creadas  usando  columnas  varchar(lOO) 
en  la  base  de  datos.  Como  otros  campos,  puedes  cambiar  el  maximo  permitido, 
usando  el  argumento  maxjength. 


FilePathField 

Un  campo  cuyas  opciones  estan  limitadas  a los  nombres  de  archivo  en  un  cierto 
directorio  en  el  sistema  de  archivos.  Tiene  tres  argumentos  especiales,  que  se 
muestran  en  la  Tabla  A-4. 


Argumento  Description 


path  Requerido,  la  ruta  absoluta  en  el  sistema  de  archivos  hacia  el 

directorio  del  cual  este  FilePathField  debe  tomar  sus  opciones  (ej.: 
"/home/images"). 


match 


Opcional;  una  expresion  regular  como  string,  que  FilePathField  usara 
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para  filtrar  los  nombres  de  archivo.  Observar  que  la  regex  sera 
aplicada  al  nombre  de  archivo  base,  no  a la  ruta  completa  (ej.: 
"foo.*\.txtA",  va  a coincidir  con  un  archivo  llamado  foo23.txt,  pero  no 
con  bar.txt  o foo23.gif). 

recursive  Opcional;  True  o False.  El  valor  por  omision  es  False.  Especifica  si 
deben  incluirse  todos  los  subdirectorios  de  path. 

alow_files  Opcional,  True  o False.  El  valor  por  omision  es  True  Especifica  si  todos 
los  los  archivos  de  los  directories  especificados  deben  ser  incluidos. 
Utiliza  este  o allow_folders  como  True. 

alow_folders  Opcional,  True  o False.  El  valor  por  omision  es  False  Especifica  si 
todas  las  carpetas  de  los  directories  especificados  deben  ser  incluidas. 
Utiliza  este  o allow_files  como  True. 


Tabla  A4  Tab/a  de  opciones  extra  de  FilePathField 
Por  supuesto,  estos  argumentos  pueden  usarse  juntos. 

El  unico  peligro  potencial  es  que  match  se  aplica  sobre  el  nombre  de  archivo  base, 
no  la  ruta  completa.  De  esta  manera,  este  ejemplo: 

FilePathField(path- ’/home/images",  match="foo.*",  recursive=T rue) 

Esto  va  a coincidir  con  /home/images/foo.gif  pero  no  con  /home/images/foo/bar.gif 
porque  el  match  se  aplica  al  nombre  de  archivo  base  (foo.gif  y bar.gif). 


FloatField 

Un  numero  de  punto  flotante,  representado  en  Python  por  una  instancia  de  float. 

IntegerField 

Similar  a FileField,  pero  valida  que  el  objeto  subido  sea  una  imagen  valida.  Tiene  dos 
argumentos  opcionales  extra: 

1.  height_field:  Nombre  del  campo  del  modelo  usado  para  auto-rellenar  con  la 
altura  de  la  imagen  cada  vez  que  se  guarde  una  instancia  de  una  imagen. 

2.  width_field:  Nombre  del  campo  del  modelo  usado  para  auto-rellenar  con 
ancho  de  la  imagen  cada  vez  que  se  guarde  una  instancia  de  una  imagen. 

Ademas  de  los  atributos  especiales  requeridos  que  estan  disponibles  para 
FileField,  un  ImageField  puede  contener  atributos  height  y width  que  corresponden  a 
la  altura  y al  ancho  de  la  imagen  en  pixeles. 

Requiere  PIL,  la  libreria  de  Imagenes  Python,  en  especial  de  Pillow. 

Por  defecto  las  instancias  de  ImageField  son  creadas  usando  columnas  varchar(lOO) 
en  la  base  de  datos.  Como  con  otros  campos,  puedes  cambiar  el  maximo  permitido, 
usando  el  argumento  maxjength. 
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IntegerField 

Un  entero.  Valores  desde  -2147483648  hasta  2147483647  son  soportados  por  Django 
de  forma  segura  en  todas  las  bases  de  datos. 

GenericIPAddressField 

Una  direccion  IP,  en  formato  string  (ej.:  "24.124.1.30"). 

NullBooleanField 

Similar  a BooleanField,  pero  permite  None/NULL  como  opciones.  Usar  este  en  lugar 
de  un  BooleanField  con  null=True. 

PositivelntegerField 

Similar  a IntegerField,  pero  debe  ser  positivo. 

PositiveSmalllntegerField 

Similar  a PositivelntegerField,  pero  solo  permite  valores  por  debajo  de  un  limite. 
Valores  desde  0 a 32767  son  soportados  de  forma  segura  en  Django. 


SlugField 

“Slug”  es  un  termino  de  la  prensa.  Un  slug  es  una  etiqueta  corta  para  algo,  que 
contiene  solo  letras,  numeros,  guiones  bajos  o simples.  Generalmente  se  usan  en 
URLs. 

De  igual  forma  que  en  CharField,  puedes  especilicarlo  con  max_length.  Si 
maxjength  no  esta  especiflcado,  Django  asume  un  valor  por  omision  de  50. 

Un  SlugField  implica  db_index=True  debido  a que  este  tipo  de  campo  se  usa 
principalmente  para  busquedas  en  la  base  de  datos. 

SlugField  acepta  una  opcion  extra,  prepopulate_from,  que  es  una  lista  de  campos 
a partir  de  los  cuales  auto-rellenar  el  slug,  via  JavaScript,  en  el  formulario  de 
administracion  del  objeto: 

models. SlugField(prepopulate_from=("pre_name",  "name")) 

prepopulate_from  no  acepta  nombres  tipo  DateTimeField  como  argumentos. 

SmalllntegerField 

Similar  a IntegerField,  pero  solo  permite  valores  en  un  cierto  rango  dependiente  de  la 
base  de  datos  (usualmente  -32,768  a +32,767). 

TextField 

Un  campo  de  texto  de  longitud  ilimitada. 
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TimeField 

Un  campo  de  hora.  Acepta  las  mismas  opciones  de  autocompletacion  de  DateField  y 
DateTimeField. 

URLField 

Un  campo  para  una  URL.  Si  la  option  verify_exists  es  True  (valor  por  omision),  se 
comprueba  la  existencia  de  la  URL  dada  (la  URL  que  arroja  y no  da  una  respuesta 
404). 

Como  los  otros  campos  de  caracteres,  URLField  toma  el  argumento  maxjength.  Si 
no  se  especifica,  el  valor  por  omision  es  200. 

UUIDField 

Un  campo  para  almacenar  Identificadores  Universales  tJnicos.  Usando  la  clase  UUID 
de  Python. 

Los  Identificadores  Universales  Unicos,  son  una  buena  alternativa  para  campos 
AutoField  que  usan  una  primary_key.  La  base  de  datos  no  genera  el  UUID,  lo  mas 
recomendable  es  usarlos  con  un  parametro  default: 

import  uuid 

from  django.db  import  models 
class  ModeloUUID(models. Model): 

id  = models. UUIDField(primary_key=  rue,  default=uuid.uuid4,  editable=  :alse) 

# Otros  campos 

Observa  como  el  llamable  (sin  parentesis)  es  pasado  a default,  no  a una  instancia 
de  UUID. 

Opciones  Universales  de  Campo 


Los  siguientes  argumentos  estan  disponibles  para  todos  los  tipos  de  campo.  Todos 
son  opcionales. 

null 

Si  esta  en  True,  Django  almacenara  valores  vacios  como  NULL  en  la  base  de  datos.  Si 
esta  en  False,  los  valores  vacios  que  se  guarden  resultaran  probablemente  en  errores 
de  la  base  de  datos.  El  valor  por  omision  es  False. 

Observa  que  los  valores  de  string  nulo  siempre  se  almacenan  como  strings  vacios, 
no  como  NULL.  Utiliza  null=True  solo  para  campos  no-string,  como  enteros, 
booleanos  y fechas.  En  los  dos  casos,  tambien  necesitaras  establecer  blank=True  si 
deseas  permitir  valores  vacios  en  los  formularios,  ya  que  el  parametro  null  solo  afecta 
el  almacenamiento  en  la  base  de  datos  (ver  la  siguiente  section,  titulada  “blank”). 

Evita  utilizar  null  en  campos  basados  en  string  como  CharField  y TextField  salvo 
que  tengas  una  excelente  razon  para  hacerlo.  Si  un  campo  basado  en  string  tiene 
null=True,  eso  significa  que  tiene  dos  valores  posibles  para  “sin  datos”:  NULL  y el 
string  vacio.  En  la  mayoria  de  los  casos,  esto  es  redundante;  la  convention  de  Django 
es  usar  el  string  vacio,  no  NULL. 


400 


APENDICE  A REFERENCIA  DE  MODELOS 


Nota:  Cuando  uses  como  base  de  datos  un  backend  de  Oracle,  la  option 
null=True  sera  usada  para  obligar  a los  campos  basados  en  cadenas  a aceptar  cadena 
vatias  como  sea  posible,  y el  valor  NULL  sera  almacenado  para  denotar  la  cadena 
vatia. 


blank 

Si  esta  en  True,  esta  permitido  que  el  campo  este  en  bianco.  El  valor  por  omision 
es  False. 

Observa  que  esto  es  diferente  de  null.  Null  solo  se  relaciona  con  la  base  de  datos, 
mientras  que  blank  esta  relacionado  con  la  validation.  Si  un  campo  tiene  un  campo 
blank=True,  la  validation  del  administrador  de  Django  permitira  la  entrada  de  un 
valor  vacio.  Si  un  campo  tiene  blank=False,  es  un  campo  requerido. 

choices 

Un  iterable  (ej.:  una  lista,  tupla,  o otro  objeto  iterable  de  Python)  de  dos  tuplas  para 
usar  como  opciones  para  este  campo. 

Si  esto  esta  dado,  la  interfaz  de  administration  de  Django  utilizara  un  cuadro  de 
selection  en  lugar  del  campo  de  texto  estandar,  y limitara  las  opciones  a las  dadas. 
Una  lista  de  opciones  se  ve  asi: 

YEARJ  N_SCHOOL_CHOICES  = ( 

('FR',  'Freshman'), 

('SO',  'Sophomore'), 

('JR',  'Junior'), 

('SR',  'Senior'), 

('GR',  'Graduate'), 

) 

El  primer  elemento  de  cada  tupla  es  el  valor  real  a ser  almacenado.  El  segundo 
elemento  es  el  nombre  legible  por  humanos  para  la  option. 

La  lista  de  opciones  puede  ser  definida  tambien  como  parte  de  la  clase  del  modelo: 

class  Foo(models. Model): 

GENDER_CHOICES  = ( 

('M',  'Male'), 

('F',  'Female'), 

) 

gender  = models. CharField(max_length=l,  choices=GENDER_CFIOICES) 

O fuera  de  la  clase  del  modelo: 

GENDER_CHOICES  = ( 

('M',  'Male'), 

('F',  'Female'), 

) 

class  Foo(models. Model): 

gender  = models. CharField(max_length=l,  choices=GENDER_CFIOICES) 
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Para  cada  campo  del  modelo  que  tenga  establecidas  choices,  Django  agregara  un 
metodo  para  recuperar  el  nombre  legible  por  humanos  para  el  valor  actual  del 
campo. 

db_column 

El  nombre  de  la  columna  de  la  base  de  datos  a usar  para  este  campo.  Si  no  esta  dada, 
Django  utilizara  el  nombre  del  campo.  Esto  es  util  cuando  estas  definiendo  un 
modelo  sobre  una  base  de  datos  existente. 

Si  tu  nombre  de  columna  de  la  base  de  datos  es  una  palabra  reservada  de  SQL,  o 
contiene  caracteres  que  no  estan  permitidos  en  un  nombre  de  variable  de  Python  (en 
particular  el  guion  simple),  no  hay  problema.  Django  quotea  los  nombres  de 
columna  y tabla  detras  de  la  escena. 

db_index 

Si  esta  en  True,  Django  creara  un  indice  en  la  base  de  datos  para  esta  columna 
cuando  cree  la  tabla  (es  decir,  cuando  ejecute  manage.py  migrate). 

db_tablespace 

El  nombre  de  la  tabla  de  la  base  de  datos  para  usar  en  este  indice  de  campo,  si  el 
campo  tiene  un  indice. 

default 

El  valor  por  omision  del  campo. 

editable 

Si  es  False,  el  campo  no  sera  editable  en  la  interfaz  de  administracion  o via 
procesamiento  de  formularios.  El  valor  por  omision  es  True. 

error_messages 

Argumento  que  permite  sobrescribir  el  mensaje  por  omision  que  el  campo  lanza. 

help_text 

Texto  de  ayuda  extra  a ser  mostrado  bajo  el  campo  en  el  formulario  de 
administracion  del  objeto.  Es  util  como  documentation  aunque  tu  objeto  no  tenga 
formulario  de  administracion. 

primary_key 

Si  es  True,  este  campo  es  la  clave  primaria  del  modelo. 

Si  no  se  especifica  primary_key=True  para  ningun  campo  del  modelo,  Django 
agregara  automaticamente  este  campo: 

d = models.AutoField('ID',  primary_key=  True) 

Por  lo  tanto,  no  necesitas  establecer  primary_key=True  en  ningun  campo,  salvo  que 
quieras  sobreescribir  el  comportamiento  por  omision  de  la  clave  primaria. 
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primary_key=True  implica  blank=False,  null=False,  y unique=True.  Solo  se 
permite  una  clave  primaria  en  un  objeto. 

unique 

Si  es  True,  el  valor  para  este  campo  debe  ser  unico  en  la  tabla. 

unique_for_date 

Asignar  como  valor  el  nombre  de  un  DateField  o DateTimeField  para  requerir  que 
este  campo  sea  unico  para  el  valor  del  campo  tipo  fecha,  por  ejemplo: 

class  Entrada(models. Model): 
fecha  = models. DateTimeField() 
slug  = models. SlugField(unique_for_date="fecha") 

# ... 

En  este  codigo,  Django  no  permitira  la  creacion  de  dos  historias  con  el  mismo  slug 
publicados  en  la  misma  fecha.  Esto  difiere  de  usar  la  restriction  unique_together  en 
que  solo  toma  en  cuenta  la  fecha  del  campo  pub_date;  la  hora  no  importa. 

unique_for_month 

Similar  a unique_for_date,  pero  requiere  que  el  campo  sea  unico  con  respecto  al  mes 
del  campo  dado. 

unique_for_year 

Similar  a unique_for_date  y unique_for_month,  pero  para  el  ano. 

verbose_name 

Cada  tipo  de  campo,  excepto  ForeignKey,  ManyToManyField,  y OneToOneField, 
toma  un  primer  argumento  posicional  opcional  - un  nombre  descrip tivo.  Si  el 
nombre  descriptivo  no  esta  dado,  Django  lo  creara  automaticamente  usando  el 
nombre  de  atributo  del  campo,  convirtiendo  guiones  bajos  en  espacios. 

En  este  ejemplo,  el  nombre  descriptivo  es  " tu  nombre 

nombre  = models. CharField("tu  nombre",  max_length=30) 

En  este  ejemplo,  el  nombre  descriptivo  es  "nombre": 

nombre  = models.  CharField(max_length=30) 

ForeignKey,  ManyToManyField,  y OneToOneField  requieren  que  el  primer 
argumento  sea  una  clase  del  modelo,  en  este  caso  hay  que  usar  verbose_name  como 
argumento  con  nombre: 

class  Encuesta(models. Model): 

pregunta  = models. ForeignKey(Pregunta,  verbose_name="preguntas  relacionadas") 

sitio  = models. ManyToManyField(Sitio,  verbose_name="lista  de  sitios' ) 

lugar  = models. OneToOneField(Lugar,  verbose_name="lugares  relacionados") 
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La  convention  es  no  capitalizar  la  primera  letra  del  verbose_name.  Django 
convertira  a mayuscula  automaticamente  la  primera  letra  cuando  lo  necesite. 


validators 

Una  lista  de  validadores  que  se  ejecutaran  para  este  campo. 


Relaciones 

Es  claro  que  el  poder  de  las  bases  de  datos  se  basa  en  relacionar  tablas  entre  si. 
Django  ofrece  formas  de  definir  los  tres  tipos  de  relaciones  mas  comunes  en  las  bases 
de  datos:  muchos-a-uno,  muchos-a-muchos,  y uno-a-uno. 

Relaciones  Muchos-a-Uno 

Para  definir  una  relation  muchos-a-uno,  usa  un  campo  tipo  ForeignKey.  El  cual  se 
usa  como  cualquier  otro  tipo  Field:  incluyendolo  como  un  atributo  de  clase  en  tu 
modelo. 

ForeignKey  requiere  un  argumento  posicional:  la  clase  a la  cual  se  relaciona  el 
modelo. 

Por  ejemplo,  si  un  modelo  Carro  tiene  un  Fabricante  - es  decir,  un  Fabricante  fabrica 
multiples  carros  pero  cada  Carro  tiene  solo  un  Fabricante  - usa  la  siguiente 
definition: 

class  Fabricante(models. Model): 

#... 

class  Carro(models. Model): 

fabricante  = models.  ForeignKey(Fabricante) 

#... 

Para  crear  una  relation  recursiva  - un  objeto  que  tiene  una  relation  muchos-a- 
uno  consigo  mismo  - usa  models.ForeignKey('self' ): 

class  Empleado(models. Model): 

manager  = models.  ForeignKey('self) 

Si  necesitas  crear  una  relation  con  un  modelo  que  aun  no  ha  sido  definido, 
puedes  usar  el  nombre  del  modelo  en  lugar  del  objeto  modelo: 

from  django.db  import  models 

class  Carro(models. Model): 

fabricante  = models. ForeignKey('Fabricante') 

# ... 

class  Fabricante(models. Model): 

# ... 
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Para  referirte  a modelos  que  han  sido  definidos  en  otra  aplicacion,  puedes 
explicitamente  especificar  un  modelo  con  el  nombre  completo  de  la  etiqueta  de  la 
aplicacion.  Por  ejemplo  si  el  modelo  Manufactura  arriba  deflnido  es  definido  en  otra 
aplicacion  llamada  production,  necesitas  usar: 

class  Carro(models. Model): 

fabricante  = models. ForeignKey('producccion.Fabricante') 

Esta  clase  de  referencia  puede  ser  util  al  resolver  dependencias  circulares  de 
importaciones  entre  dos  aplicaciones. 

Toma  en  cuenta  que  cada  vez  que  creas  una  relacion  foranea,  se  crea  un  un  indice 
en  la  base  de  datos  de  forma  automatica.  Puedes  desactivar  este  comportamiento 
fijando  db_index  = False,  en  el  archivo  del  modelo.  Si  quieres  evitar  la  sobrecarga  que 
ocasiona  un  indice,  o si  estas  creando  un  indice  alternativo. 


^Advertencia:  No  es  recomendable  tener  un  campo  ForeignKey  de  una  aplicacion 
sin  migraciones,  enlazado  a una  aplicacion  con  las  migraciones  aplicadas. 


Detras  de  escena,  Django  agrega  "_id"  al  nombre  de  campo  para  crear  su  nombre 
de  columna  en  la  base  de  datos.  En  el  ejemplo  anterior,  la  tabla  de  la  base  de  datos 
correspondiente  al  modelo  Carro,  tendra  una  columna  fabricante_id.  (Puedes 
cambiar  esto  explicitamente  especificando  db_column;  ver  mas  arriba  en  la  section 
“db_column”.)  De  todas  formas,  tu  codigo  nunca  debe  utilizar  el  nombre  de  la 
columna  de  la  base  de  datos,  salvo  que  escribas  tus  propias  SQE.  Siempre  te 
manejaras  con  los  nombres  de  campo  de  tu  objeto  modelo. 

Se  sugiere,  pero  no  es  requerido,  que  el  nombre  de  un  campo  ForeignKey  (fabricante 
en  el  ejemplo)  sea  el  nombre  del  modelo  en  minusculas.  Por  supuesto,  puedes 
ponerle  el  nombre  que  quieras.  Por  ejemplo: 

class  Carro(models. Model): 

fabrica_de_autos  = models. ForeignKey(Fabricante) 

# ... 

Los  campos  ForeignKey  reciben  algunos  argumentos  extra  para  definir  como  debe 
trabajar  la  relacion  (ver  Tabla  A- 5).  Todos  son  opcionales. 


Argumento  Description 


limit_choices_to  Establece  un  limite  a las  opciones  disponibles  para  el  campo, 

cuando  es  renderizado  usando  ModelForm  en  el  admin  (por 
omision,  todos  los  objetos  de  el  queryset  estan  disponibles 
para  elegir).  Usa  un  diccionario,  un  objeto  Q,  o un  llamable 
que  devuelva  un  diccionario,  o un  objeto  Q que  puede  ser 
utilizado. 

Por  Ejemplo: 


staff_member=models.ForeignKey( 
limit_choices_to={'is_staff:  True} 

Esto  hace  que  el  campo  correspondiente  en  ModelForm  liste 
unicamente  Users  que  tengan  asignado  is_staff=True. 
related_name  El  nombre  a utilizar  para  la  relacion  desde  el  objeto 

relacionado  hacia  el  objeto  con  el  que  se  relaciona. 
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related_query_name 

El  nombre  a utilizar  para  el  nombre  inverso  del  filtro  del 
modelo.  Remplaza  el  valor  de  related_name  si  se  establece,  de 
otra  manera  sera  el  valor  por  defecto  del  nombre  del  modelo: 

# Declara  el  campo  foraneo  con  "related_query_name" 

class  Tag(models. Model): 

articulo  = models. ForeignKey(Articulo, 

related_name  “tags’ -related_query_name- 'tag") 
nombre  = models.  CharField(max_length=255) 

# Este  ahora  es  el  nombre  del  filtro  inverso 

Articulo. objects. filter(tag_name  = "importante") 

to_field 

El  campo  en  el  objeto  relacionado  con  el  cual  se  establece  la 
relation.  Por  omision,  Django  usa  la  clave  primaria  del  objeto 
relacionado. 

db_constraint 

Regula  la  creation  o no  de  restricciones  en  la  base  de  datos 
para  la  clave  foranea.  Por  omision  es  True,  la  mayoria  de  las 
veces  sera  cierto,  Usar  False  puede  ser  muy  malo  para  la 
integridad  de  los  datos.  Dicho  esto,  aqul  hay  algunos 
escenarios  donde  podrfas  querer  hacer  esto: 

Tienes  datos  heredados  que  no  son  validos. 

Tu  base  de  datos  esta  rota. 

on_delete 

Cuando  un  objeto  referenciado  por  un  campo  ForeignKey  es 
borrado.  Django  por  omision  emula  el  comportamiento  de  las 
restricciones  SQL  ON  DELETE  CASCADE  y borra  tambien  el 
objeto  que  contiene  el  campo  ForeignKey. 

Este  comportamiento  puede  ser  sobrescrito  usando  algun 
argumento  con  on_delete  como  los  siguientes: 

CASCADE:  Borra  en  cascada,  el  comportamiento  por  omision. 
PROTECT:  Previene  que  se  borre  la  referenda  a un  objeto. 
SET_NULL  Fija  un  campo  ForeignKey  a null;  siempre  y 
cuando  use  null  = True. 

SET_DEFAULT  Fija  un  campo  ForeignKey  como  el  valor  por 
omision. 

SET()  Fija  un  campo  ForeignKey  con  el  valor  pasado  a SET(),  o 
mediante  un  llamable. 

Por  ejemplo  si  quieres  tener  un  campo  ForeignKey  que 
contenga  valores  nulos,  cuando  el  objeto  sea  borrado  utiliza  lo 
siguiente: 

user  = models.ForeignKey(User,  blank=True,  null=True, 
on_delete=models.SET_NU  LL) . 

DO_NOTHING 

No  toma  ninguna  action. 

Tabla  A5  Opciones  de  ForeignKey 

Relaciones  Muchos  a Muchos 


Para  definir  una  relation  muchos-a-muchos,  usa  un  campo  ManyToManyField.  A1 
igual  que  los  campos  ForeignKey,  ManyToManyField  requiere  un  argumento 
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posicional:  la  clase  a la  cual  se  relaciona  el  modelo,  trabaja  de  igual  forma  que  los 
campos  ForeignKey,  incluyendo  relaciones  recursivas  y perezosas. 

Por  ejemplo,  si  una  Pizza  tiene  multiples  objetos  Ingredientes  - es  decir,  un 
Ingrediente  puede  estar  en  multiples  pizzas  y cada  Pizza  tiene  multiples  ingredientes 
(ingredientes)  - debe  representarse  asi: 


class  lngredientes(models. Model): 

#... 

class  Pizza(models. Model): 

ingredientes  = models. ManyToManyField(lngredientes) 


Como  sucede  con  ForeignKey,  una  relation  de  un  objeto  con  si  mismo  puede 
definirse  usando  el  string  'self'  en  lugar  del  nombre  del  modelo,  y puedes  hacer 
referencia  a modelos  que  todavra  no  se  definieron  usando  un  string  que  contenga  el 
nombre  del  modelo.  De  todas  formas  solo  puedes  usar  strings  para  hacer  referencia  a 
modelos  dentro  del  mismo  archivo  models.py  - no  puedes  usar  un  string  para  hacer 
referencia  a un  modelo  en  una  aplicacion  diferente,  o hacer  referencia  a un  modelo 
que  ha  sido  importado  de  cualquier  otro  lado. 

Se  sugiere,  pero  no  es  requerido,  que  el  nombre  de  un  campo  ManyToManyField 
(ingredientes,  en  el  ejemplo)  sea  un  termino  en  plural  que  describa  al  conjunto  de 
objetos  relacionados  con  el  modelo. 

Detras  de  la  escena,  Django  crea  una  tabla  join  intermedia  para  representar  la 
relation  muchos-a-muchos. 

No  importa  cual  de  los  modelos  tiene  el  ManyToManyField,  pero  es  necesario  que 
este  en  uno  de  los  modelos  - no  en  los  dos. 

Si  estas  usando  la  interfaz  de  administration,  las  instancias  ManyToManyField 
deben  ir  en  el  objeto  que  va  a ser  editado  en  la  interfaz  de  administration.  En  el 
ejemplo  anterior,  los  ingredientes  estan  en  la  Pizza  (en  lugar  de  que  el  Ingredientes 
tenga  pizzas  ManyToManyField  ) porque  es  mas  natural  pensar  que  una  Pizza  tiene 
varios  Ingredientes  que  pensar  que  un  ingrediente  esta  en  muchas  pizzas.  En  la 
forma  en  que  esta  configurado  el  ejemplo,  el  formulario  de  administration  de  el 
objeto  "Pizza"  permitira  que  los  usuarios  seleccionen  los  ingredientes. 

Los  objetos  ManyToManyField  toman  algunos  argumentos  extra  para  definir 
como  debe  trabajar  la  relation  (ver  Tabla  A-6).  Todos  son  opcionales. 


Argumento  Description 


related_name  El  nombre  a utilizar  para  la  relation  desde  el  objeto 

relacionado  hacia  este  objeto. 

related_query_name  El  nombre  a utilizar  para  el  nombre  inverso  del  filtro  del 

modelo.  Remplaza  el  valor  de  related_name  si  se  establece,  de 
otra  manera  sera  el  valor  por  defecto  del  nombre  del  modelo. 

limit_choices_to  Ver  la  description  en  ForeignKey.  limit_choices_to  no  tiene 

efecto  cuando  es  usado  con  una  tabla  intermedia  especificada 
usando  el  parametro  througth 


symmetrical 


Solo  utilizado  en  la  definition  de  ManyToManyField  sobre  si 
mismo.  Considera  el  siguiente  modelo: 
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through 


throughjields 


class  Persona(models. Model): 

friends  = models. ManyToManyField("self") 

Cuando  Django  procesa  este  modelo,  identifica  que  tiene  un 
ManyToManyField  sobre  si  mismo,  y como  resultado,  no 
agrega  un  atributo  persona_set  a la  clase  Persona.  En  lugar  de 
eso,  se  asumen  que  el  ManyToManyField  es  simetrico  - esto 
es,  si  yo  soy  tu  amigo,  entonces  tu  eres  mi  amigo. 

Si  no  deseas  la  simetria  en  las  relaciones  ManyToMany  con 
self,  establece  symmetrical  en  False.  Esto  forzara  a Django  a 
agregar  el  descriptor  para  la  relation  inversa,  permitiendo  que 
las  relaciones  ManyToMany  sean  asimetricas. 

Django  automaticamente  genera  una  tabla  para  manejar  las 
relaciones  muchos  a muchos.  Si  quieres  especificar  una  tabla 
intermedia,  puedes  usar  la  option  through  para  especificar  el 
modelo  Django  que  representara  la  tabla  intermedia  que 
quieras  usar. 

Los  casos  mas  comunes  para  usar  esta  option  es  cuando 
quieres  asociar  datos  extras  con  relaciones  muchos  a muchos. 
Si  no  especificas  expllcitamente  un  modelo  con  through, 
todavla  hay  impllcita  una  clase  del  modelo  through,  que 
puedes  usar  directamente  para  crear  las  tablas  y sus 
asociaciones.  Tiene  tres  campos: 
id:  La  clave  primaria  de  la  relation. 

<containing_model>_id:  El  id  del  modelo  que  declara  la 
relation  ManyToManyField. 

<other_model>_id:  El  id  del  modelo  que  enlaza  a 

ManyT  oManyField 

Usado  unicamente  en  modelos  intermedios  personalizados. 
Django  normalmente  determina  el  campo  intermedio  de  un 
modelo  que  se  usara  para  establecer  el  orden  en  una  relation 
muchos  a muchos  automaticamente.  Considera  el  siguiente 
ejemplo: 

from  django.db  import  models 

class  Persona(models. Model): 

nombre  = models.  CharField(max_length=50) 

class  Grupo(models. Model): 

nombre  = models.  CharField(max_length=128) 
miembros  = models. ManyToManyField(Persona, 
through- mienbros',  through_fields=('grupo', 

'persona')) 

class  Mienbros(models. Model): 
grupo  = models. ForeignKey(Group) 
persona  = models.  ForeignKey(Person) 
invitados  = models. ForeignKey(Person, 
related_name="mienbrosJnvitados") 
razonjnvitacion  = models.  CharField(max_length=64) 

Miembros  tiene  dos  claves  foraneas  Persona  (persona  e 
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invitados)  lo  cual  hace  que  la  relation  sea  ambigua  y Django 
no  sepa  cual  utilizar.  En  este  caso,  debes  expllcitamente 
especificar  cual  clave  foranea  debera  utilizar  Django,  usando 
through_lields,  como  en  el  modelo  Grupo. 
through_fields  acepta  2 tuplas  ('fleldl',  'field2'),  donde  fieldl 
es  el  nombre  de  la  clave  foranea  del  modelo  de  la  clase 
ManyToManyField  donde  esta  definido  con  (grupo  en  este 
caso),  y field2  es  el  nombre  de  la  clave  foranea  con  el  campo 
del  modelo. 

Cuando  se  usan  mas  de  una  clave  foranea  en  un  modelo 
intermedio  para  cualquiera  (o  ambos)  de  los  modelos 
participantes  en  la  relation  muchos  a muchos,  es  necesario 
especificar  l h ro  u gh_fi  el d s . Esto  tambien  se  aplica  a relaciones 
recursivas,  cuando  un  modelo  intermedio  es  usado  con  mas 
de  dos  claves  foraneas  en  un  modelo,  o si  deseas 
expllcitamente  especificar  cual  de  los  dos  debe  usar  Django. 

swappable  Controla  la  reaccion  del  framework  de  migraciones,  si  el 

campo  ManyToManyField  apunta  a un  modelo 

intercambiable  o swappable,  Si  este  es  True  -el  valor  por 
omision,  el  campo  ManyToManyField'  apunta  al  modelo  con 
el  cual  coincide  el  valor  actual  de  settings. 

AUTEl_USER_MODEL  (u  otra  configuracion  de  un  modelo  de 
intercambio),  la  relacion  sera  almacenada  en  la  migracion 
usando  una  referencia  a la  configuracion,  no  al  modelo 
directamente. 

Unicamente  querrias  sobrescribir  esto  a False  si  estas  seguro 
de  que  tu  modelo  apunta  siempre  hacia  el  modelo 
intercambiable  - por  ejemplo,  si  es  un  modelo  disenado 
especiflcamente  para  un  modelo  de  usuario  personalizado. 

Por  ultimo,  toma  en  cuenta  que  los  campos 

ManyToManyField  no  soportan  validadores  y que  null  no 
tiene  efecto  ya  que  no  es  requerido  en  una  relacion  a nivel  de 
base  de  datos. 

db_table  El  nombre  de  la  tabla  a crear  para  almacenar  los  datos  de  la 

relacion  muchos-a-muchos.  Si  no  se  provee,  Django  asumira 
un  nombre  por  omision  basado  en  los  nombres  de  las  dos 
tablas  a ser  vinculadas. 

db_constraint  Como  en  los  campos  ForeignKey,  regula  la  creacion  o no  de 

restricciones  en  la  base  de  datos  para  la  clave  foranea.  El  valor 
pordefecto  es  True 

Tabla  A6  Opciones  de  un  campo  ManyToManyField 


Relaciones  uno  a uno 

Una  relacion  uno-a-uno,  es  conceptualmente  muy  parecida  a una  relacion  foranea  o 
ForeignKey  con  un  parametro  unique=True,  solo  que  el  lado  “inverso”  de  la  relacion 
devuelve  directamente  un  unico  objeto. 
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Esto  es  mas  util  como  la  clave  primaria  de  un  modelo  que  “extiende”  otro  modelo 
de  la  misma  forma;  la  herencia  multi-tablas  es  implementada  agregando 
implicitamente  una  relacion  uno  a uno  del  modelo  hijo  al  modelo  padre. 

Un  argumento  posicional  es  requerido,  la  clase  a la  cual  el  modelo  se  relaciona. 
Esto  funciona  exactamente  de  la  misma  forma  en  que  lo  hace  para  ForeignKey 
incluyendo  todas  las  opciones  incluyendo  relaciones  recursivas  y perezosas. 

Adicionalmente  OneToOneField  acepta  todos  los  argumentos  extras  aceptados  por 
un  campo  ForeignKey,  mas  un  argumento  extra. 

parentjink:  Cuando  es  True  y es  usado  en  un  modelo  el  cual  hereda  de  otro  modelo 
(concretamente)  indica  que  el  campo  se  debe  utilizar  para  enlazar  la  clase  padre,  en 
lugar  de  el  extra  OneToOneField  que  normalmente  seria  creado  implicitamente  por 
la  subclase 

Si  no  especificas  el  nombre  para  el  argumento  related_name  en  un  campo 
OneToOneField,  Django  usara  el  nombre  del  modelo  en  minusculas,  como  el  valor 
por  default.  Por  ejemplo: 

from  django.conf  import  settings 
from  django.db  import  models 

class  UsuarioEspecial (models. Model): 

user  = models. OneToOneField(settings.AUTH_USER_MODEL) 
supervisor  = models. OneToOneField(settings.AUTH_USER_MODEL, 
related_name- supervisor') 

El  modelo  User  tendra  los  siguientes  atributos: 

»>  user  = User. objects. get(pk=l) 

»>  hasattr(user,  'usuarioespecial') 

True 

»>  hasattr(user,  'supervisor') 

True 

Una  exception  del  tipo  DoesNotExist  es  lanzada  cuando  se  accede  a la  relacion 
inversa  de  una  entrada  de  una  tabla  que  no  existe.  Por  ejemplo,  si  un  user  no  tiene  un 
supervisor  definido  en  UsuarioEspecial: 

»>  user. supervisor 
Traceback  (most  recent  call  last): 

DoesNotExist:  User  matching  query  does  not  exist. 


Opciones  de  los  Metadatos  de  un  Modelo 

Eos  metadatos  especificos  de  un  modelo  viven  en  una  clase  Meta  definida  en  el 
cuerpo  de  la  clase  del  modelo: 

class  Libro(models. Model): 

titulo  = models.  CharField(max_length=100) 

class  Meta: 

# Los  metadatos  van  aqui 
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Los  metadatos  del  modelo  son  “ cualquier  cosa  que  no  sea  un  campo” , como 
opciones  de  ordenamiento,  nombre  en  plural,  etc. 

Las  secciones  que  siguen  presentan  una  lista  de  todas  las  posibles  opciones  Meta. 
Ninguna  de  estas  opciones  es  requerida.  Agregar  clases  Meta  a un  modelo  es 
completamente  opcional. 

abstract 

Si  es  True,  este  modelo  sera  una  clase  base  abstracta. 


db_table 

El  nombre  de  la  tabla  de  la  base  de  datos  a usar  para  el  modelo. 

Para  ahorrarte  tiempo,  Django  deriva  automaticamente  el  nombre  de  la  tabla  de 
la  base  de  datos  a partir  del  nombre  de  la  clase  modelo  y la  aplicacion  que  la 
contiene.  Un  nombre  de  tabla  de  base  de  datos  de  un  modelo  se  construye  uniendo 
la  etiqueta  de  la  aplicacion  del  modelo  - el  nombre  que  usaste  en  manage.py 
startapp  - con  el  nombre  de  la  clase  modelo,  con  un  guion  bajo  entre  ellos. 

Por  ejemplo,  si  tienes  una  aplicacion  biblioteca  (creada  por  manage.py  startapp 
biblioteca),  un  modelo  definido  como  class  Libro  tendra  una  tabla  en  la  base  de  datos 
llamada  libros. 

Para  sobreescribir  el  nombre  de  la  tabla  de  la  base  de  datos,  use  el  parametro 
db  _table  dentro  de  class  Meta: 

class  Libro(models. Model): 

class  Meta: 

db_table  = 'un_nombre_cualquiera' 

Si  no  se  define,  Django  utilizara  appjabel  + + model_class_name. 

Si  tu  nombre  de  tabla  de  base  de  datos  es  una  palabra  reservada  de  SQL,  o 
contiene  caracteres  que  no  estan  permitidos  en  los  nombres  de  variable  de  Python 
(especialmente  el  guion  simple),  no  hay  problema.  Django  entrecomilla  los  nombres 
de  tabla  y de  columna  detras  de  la  escena. 

db_tablespace 

El  nombre  de  la  tabla  de  la  base  de  datos  para  usar  por  el  modelo.  Si  el  backend 
no  soporta  tablespaces,  esta  option  sera  ignorada. 

get_latest_by 

El  nombre  de  un  DateField  o DateTimeField  del  modelo.  Esto  especifica  el  campo  a 
utilizar  por  omision  en  el  metodo  latest!)  del  Manager  del  modelo. 

Aqui  hay  un  ejemplo: 

get_latest_by  = "fecha_publicacion" 
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managed 

Por  defecto  es  True,  lo  cual  signiflca  que  Django  creara  las  apropiadas  tablas  de  la 
base  de  datos  en  las  migraciones,  o como  parte  de  las  migraciones  y las  removera 
como  parte  del  comando  flush.  Es  decir,  Django  maneja  los  ciclos  vitales  de  las  tablas 
de  la  base  de  datos. 

Si  es  False,  no  se  realizara  ningunas  operaciones  de  creation  o borrado  de  la  tabla 
de  base  de  datos  para  este  modelo.  Esto  es  util  si  el  modelo  representa  una  tabla 
existente  o una  vista  de  la  base  de  datos  que  se  ha  creado  por  algun  otro  medio.  Esta 
es  la  unica  diferencia  cuando  usas  managed=False.  El  resto  de  los  aspectos  del 
manejo  del  modelo  son  exactamente  iguales  que  los  de  uno  normal.  Esto  incluye 

Agregar  una  clave  primaria  automaticamente  al  modelo  si  no  se  declara  una.  Para 
evitar  confusiones,  para  los  que  lean  el  codigo,  es  recomendable  especificar  todas  las 
columnas  de  la  base  de  datos  que  se  estan  modelando,  aun  cuando  se  esten  usando 
modelos  unmanaged 

Si  el  modelo  con  managed=False  contiene  un  campo  ManyToManyField  que 
enlace  otro  modelo  unmanaged,  en  lugar  de  una  tabla  intermedia  para  juntar  la  tabla 
muchos  a muchos  esta  no  se  creara.  Sin  embargo,  una  tabla  intermediaria  entre  un 
modelo  managed  y un  unmanaged  si  se  puede  crear. 

Si  necesitas  cambiar  este  comportamiento  por  defecto,  crea  una  tabla  intermedia 
como  un  modelo  explicito  (con  managed  segun  lo  necesitado)  y usa  el  atributo 
through  para  hacer  que  la  relation  use  un  modelo  personalizado. 

Para  pruebas  que  incluyan  modelos  con  managed=False,  necesitas  asegurarte  que 
se  estan  creando  las  tablas  correctas,  como  parte  de  las  pruebas. 

Si  estas  interesado  en  cambiar  el  comportamiento  a nivel-Python  de  un  modelo  de 
una  clase,  puedes  usar  managed=False  y crear  una  copia  de  un  modelo  existente.  Sin 
embargo  existe  una  mejor  forma  de  aprovechar  esta  situation:  usa  proxy-models 

ordering 

El  ordenamiento  por  omision  del  objeto,  utilizado  cuando  se  obtienen  listas  de 
objetos: 

ordering  = ['-fecha_publicacion'] 

Esta  es  una  tupla  o lista  de  cadenas  o strings.  Cada  string  es  un  nombre  de  campo 
con  un  prefljo  opcional  -,  que  indica  orden  descendiente.  Los  campos  sin  un  - 
precedente  se  ordenaran  en  forma  ascendente.  Use  el  string  "?"  para  ordenar  al  azar. 


Nota:  No  es  recomendable  tener  un  campo  ForeignKey  de  una  aplicacion  sin 
migraciones,  enlazado  a una  aplicacion  con  las  migraciones  aplicadas. 


Sin  importar  de  cuantos  campos  consista  ordering,  el  sitio  administrative 
unicamente  usara  el  primer  campo. 

Por  ejemplo,  para  ordenar  por  un  campo  titulo  en  orden  ascendente  (A-Z),  usa 
esto: 

ordering  = ['titulo'] 

Para  ordenar  por  titulo  en  orden  descendente  (Z-A),  usa  esto: 
ordering  = ['-titulo'] 

Para  ordenar  por  titulo  en  orden  descendente,  y luego  por  autor  en  orden 
ascendente,  usa  esto: 
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ordering  = ['-titulo',  'autor'] 


order_with_respect_to 

Marca  este  objeto  como  “ordenable”  con  respecto  al  campo  dado.  Esto  se  utiliza  casi 
siempre  con  objetos  relacionados  para  permitir  que  puedan  ser  ordenados  respecto  a 
un  objeto  padre.  Por  ejemplo,  si  una  Answer  se  relaciona  a un  objeto  Question,  y una 
pregunta  tiene  mas  de  una  respuesta,  y el  orden  de  las  respuestas  importa,  haras  esto: 

Class  Respuesta(models. Model): 

pregunta  = models.  ForeignKey(Pregunta) 

# ... 

class  Meta: 

order_with_respect_to  = 'pregunta' 

order_with_respect_to  agrega  un  campo  a la  base  de  datos,  en  especifico  una 
columna  llamada  _order,  asi  que  asegurate  que  los  cambios  sea  aplicados 
correctamente  en  cada  migration,  si  agregas  o cambias  order_with_respect_to 
despues  de  la  inicial  migration. 

proxy 

Si  se  establece  en  True,  un  modelo  de  una  subclase  de  otro  modelo,  sera  tratado 
como  un  modelo  proxi. 

unique_together 

Conjuntos  de  nombres  de  campo  que  tornados  juntos  deben  ser  unicos: 
unique_together  = (("driver",  "restaurante"),) 


Esto  es  una  lista  de  listas  de  campos  que  deben  ser  unicos  cuando  se  consideran 
juntos.  Es  usado  en  la  interfaz  de  administration  de  Django  y se  refuerza  a nivel  de 
base  de  datos  (esto  es,  se  incluyen  las  sentencias  UNIQUE  apropiadas  en  la  sentencia 
CREATE  TABLE). 

verbose_name 

Un  nombre  legible  por  humanos  para  el  objeto,  en  singular: 
verbose_name  = "pizza" 

Si  no  se  define,  Django  utilizara  una  version  adaptada  del  nombre  de  la  clase,  en  la 
cual  CamelCase  se  convierte  en  camel  case. 

verbose_name_plural 

El  nombre  del  objeto  en  plural: 
verbose_name_plural  = "historias" 
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Si  no  se  define,  Django  agregara  una  “s”  al  final  del  verbose_name. 

Opciones  del  Administrador 

ModelAdmin 

La  clase  ModelAdmin  le  dice  a Django  como  mostrar  el  modelo  en  el  sitio  de 
administracion. 

Usualmente  se  almacena  en  el  archivo  admin.py  dentro  de  la  aplicacion  (el 
comando  startapp  crea  el  archivo  admin.py). 

Por  ejemplo: 

from  biblioteca.models  import  Autor 

class  lnterfazAutor(admin. ModelAdmin): 

pass 

admin. site. register(Author,  InterfazAutor) 

De  forma  predeterminada  la  clase  ModelAdmin  registra  todos  los  valores  del 
modelo,  si  esto  es  lo  que  buscas  una  manera  muy  sencilla  de  simplificar  el  ejemplo 
anterior  es  usando  lo  siguiente 

from  django.contrib  import  admin 
from  bibloiteca.models  import  Autor 

admin. site. register(Autor) 

Tambien  puedes  usar  un  decorador,  para  registrar  la  clase  ModelAdmin, 
directamente  en  el  modelo: 

from  django.contrib  import  admin 
from  .models  import  Autor 

@admin.register(Author) 

class  AuthorAdmin(admin. ModelAdmin): 

pass 

Las  siguientes  secciones  presentan  una  lista  de  alguna  de  las  opciones  que  acepta 
la  clase  ModelAdmin  para  personalizar  sus  atributos.  Ninguna  de  estas  opciones  es 
requerida.  Para  utilizar  una  interfaz  de  administracion. 

date_hierarchy 

Establece  datejiierarchy  con  el  nombre  de  un  DateField  o DateTimeField  en  tu 
modelo,  y la  pagina  de  la  lista  de  cambios  incluira  una  navegacion  basada  en  la  fecha 
usando  ese  campo. 

Aqui  hay  un  ejemplo: 
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# Archivo  models. py 

class  Libro(models. Model): 

fecha  = models. DateTimeFieldQ 


# Archivo  admin. py 

from  biblioteca.models  import  Autor 

class  InterfazLibro(admin.ModelAdmin): 
date_hierarchy  = "fecha" 

admin. site. register(Libro,  InterfazLibro) 


Este  atributo,  establece  la  lista  de  nombres  de  campos  que  se  deben  excluir  de  un 
formulario. 

Por  ejemplo,  considera  el  siguiente  modelo: 

from  django.db  import  models 

class  Autoi  (models. Model): 

nombre  = models.  CharField(max_length=100) 

titulo  = models.  CharField(max_length=3) 

fecha_nacimiento  = models. DateField(blank=  , null=  ue) 


Si  solo  quieres  incluir  en  un  formulario  del  modelo  Autor  los  campos  nombre  y 
titulo,  puedes  especificarlos  a traves  de  exclude  de  la  siguiente  forma: 

from  django.contrib  import  admin 

class  AutorAdmin(admin.ModelAdmin): 
fields  = ('nombre',  'titulo') 


class  AutorAdmin(admin.ModelAdmin): 
exclude  = ('fecha_nacimiento',) 

fields 

Una  tupla  de  nombres  de  campo  a mostrar  en  el  conjunto  de  campos.  Esta  clave  es 
requerida. 

Para  mostrar  multiples  campos  en  la  misma  linea,  encierra  esos  campos  en  su 
propia  tupla.  En  este  ejemplo,  los  campos  nombre  y apellido  se  mostraran  en  la 
misma  linea. 

Por  ejemplo,  para  definir  un  simple  formulario  de  un  modelo  de 
django.contrib. flatpages. models. FlatPage,  podemos  usar  fields  asi: 

class  FlatPageAdmin(admin.ModelAdmin): 
fields  = ('url',  'title',  'content') 


Nota:  La  opcion  fields  no  deve  de  confundirse  con  el  diccionario  fields  de  el 
atributo  de  la  opcion  fieldsets,  de  la  siguiente  seccion. 
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fieldsets 

Establece  fieldsets  para  controlar  la  disposition  de  las  paginas  “agregar”  y 
“modificar”  de  la  interfaz  de  administracion. 

fieldsets  es  una  estructura  anidada  bastante  compleja  que  se  demuestra  mejor  con 
un  ejemplo.  Lo  siguiente  esta  tornado  del  modelo  FlatPage  que  es  parte  de 
django.contrib.flatpages: 

from  django.contrib  import  admin 

class  FlatPageAdmii  (admin. ModelAdmin): 
fieldsets  = ( 

(None,  { 

'fields':  ('url',  'title',  'content',  'sites') 

})■ 

('Advanced  options',  { 

'classes':  ('collapse',), 

'fields':  ('enable_comments',  'registration_required',  ’template_name  ) 

}), 

) 


Formalmente,  fields  es  una  lista  de  tuplas  dobles,  en  la  que  cada  tupla  doble 
representa  un  <fieldset>  en  el  formulario  de  la  pagina  de  administracion.  (Un 
<fieldset>  es  una  “seccion”  del  formulario.) 

Fas  tuplas  dobles  son  de  la  forma  (name,  field_options),  donde  name  es  un  string 
que  representa  el  titulo  del  conjunto  de  campos,  y field_options  es  un  diccionario  de 
information  acerca  del  conjunto  de  campos,  incluyendo  una  lista  de  los  campos  a 
mostrar  en  el. 

Si  fields  no  esta  definido,  Django  mostrara  por  omision  cada  campo  que  no  sea  un 
AutoField  y tenga  editable=True,  en  un  conjunto  de  campos  simple,  en  el  mismo 
orden  en  que  aparecen  los  campos  definidos  en  el  modelo. 

El  diccionario  field_options  puede  tener  la  clave  que  se  describen  en  la  siguiente 
seccion. 

• fields 

Una  tupla  de  nombres  de  campo  a mostrar  en  el  conjunto  de  campos.  Esta  clave 

es  requerida.  Ejemplo: 

{ 

'fields':  (nombre',  'apellido',  'domicilio',  'ciudad',  'estado'), 

} 

Para  mostrar  multiples  campos  en  la  misma  linea,  encierra  esos  campos  en  su 
propia  tupla.: 

{ 

'fields’:  (('nombre',  'apellido'),  'domicilio',  'ciudad',  'estado'), 

} 


• clases 


Un  string  conteniendo  clases  extra  CSS  para  aplicar  al  conjunto  de  campos. 
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Ejemplo: 

{ 

'classes':  ('wide',  'extrapretty'), 

} 

Dos  clases  utiles  definidas  por  la  hoja  de  estilo  del  sitio  de  administracion  por 
omision  son  collapse  y wide.  Los  conjuntos  de  campos  con  el  estilo  collapse  seran 
colapsados  inicialmente  en  el  sitio  de  administracion  y reemplazados  por  un 
pequeno  enlace  “click  to  expand”.  Los  conjuntos  de  campos  con  el  estilo  wide 
tendran  espacio  horizontal  extra. 

• description 

Un  string  de  texto  extra  opcional  para  mostrar  encima  de  cada  conjunto  de 
campos,  bajo  el  encabezado  del  mismo.  Se  usa  tal  cual  es,  de  manera  que  puedes 
usar  cualquier  HTML,  y debes  crear  las  secuencias  de  escape  correspondientes 
para  cualquier  caracter  especial  HTML  (para  evitar  problemas  de  seguridad). 

list_display 

Establece  list_display  para  controlar  que  campos  se  muestran  en  la  pagina  de  la  lista 
de  del  administrador. 

Ejemplo: 

list_display  = ('nombre',  apellido') 

Si  no  se  define  list_display,  el  sitio  de  administracion  mostrara  una  columna 

simple  con  la  representation str ()  de  cada  objeto. 

Aqui  hay  algunos  casos  especiales  a obsevar  acerca  de  list_display: 

• Si  el  campo  es  una  LoreignKey,  Django  mostrara  el  str ()  del  objeto 

relacionado. 

• No  se  admiten  los  campos  ManyToManyLield,  porque  eso  implicaria  la 
ejecucion  de  una  sentencia  SQL  separada  para  cada  fila  en  la  tabla.  Si  de  todas 
formas  quieres  hacer  esto,  dale  a tu  modelo  un  metodo  personalizado,  y 
agrega  el  nombre  de  ese  metodo  a list_display.  (Mas  information  sobre 
metodos  personalizados  en  list_display  en  breve.) 

• Si  el  campo  es  un  BooleanLield  o NullBooleanLield,  Django  mostrara  unos 
bonitos  iconos  “on”  o “off”  en  lugar  de  True  o Lalse. 

• Si  el  string  dado  es  un  metodo  del  modelo,  Django  lo  invocara  y mostrara  la 
salida.  Este  metodo  debe  tener  un  atributo  de  funcion  short_description  para 
usar  como  encabezado  del  campo. 

Aqui  esta  un  modelo  de  ejemplo  completo: 

from  django.db  import  models 

from  django.contrib  import  admin 

from  django.utils.html  import  format_html 

class  Persona(models. Model): 

nombre  = models.  CharField(max_length=50) 
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apellido  = models.  CharField(max_length=50) 
color_codigo  = models.  CharField(max_length=6) 

def  nombre_coloreado(self): 

return  format_html('<span  style- 'color:  #{0};">{1}  {2}</span>', 
self.color_codigo, 
self.nombre, 
sell  .apellido) 

nombre_coloreado.allow_tags  = 

class  PersonAdmir  (admin. ModelAdmin): 

list  display  = ('nombre',  'apellido',  'nombre_coloreado') 


Si  el  string  dado  es  un  metodo  del  modelo  que  retorna  True  o False,  Django 
mostrara  un  bonito  icono  “on”  o “off’  si  le  das  al  metodo  un  atributo  boolean  con 
valor  enTrue. 

Aqui  esta  un  modelo  de  ejemplo  completo: 

class  Persor  (models. Model): 

nombre  = models.  CharField(maxlength=50) 
fecha_nacimiento  = models.  DateField() 

class  Admin: 

list_display  = ('nombre',  'fecha_nacimiento') 

def  nacido_cincuentas(:;e!f): 

return  self.fecha_nacimiento.strftime('%Y')[:3]  ==  5 

nacido_cincuentas. boolean  = 

Los  metodos  str ()  son  tan  validos  en  list_display  como  cualquieras  otro 

metodo  del  modelo,  por  lo  cual  esta  perfectamente  bien  hacer  esto: 

list_display  = (' str ',  'algun_otro_campo') 

Usualmente,  los  elementos  de  list_display  que  no  son  campos  de  la  base  de  datos 
no  pueden  ser  utilizados  en  ordenamientos  (porque  Django  hace  todo  el 
ordenamiento  a nivel  de  base  de  datos). 

Django  trata  de  interpretar  cada  elemento  delist_displaye n este  orden: 

• Un  campo  de  un  modelo. 

• Un  llamable. 

• Una  cadena  de  representation  de  un  atributo  ModelAdmin. 

• Una  cadena  de  representation  de  un  atributo  de  un  modelo. 

list_display_links 


Establece  list_display_links  para  controlar  cuales  campos  de  list_display  deben  ser 
vinculados  a la  pagina  de  cambios  de  un  objeto. 

Por  omision,  la  pagina  de  la  lista  de  cambios  vinculara  la  primera  columna  - el 
primer  campo  especificado  en  list_display  - a la  pagina  de  cambios  de  cada  item. 
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Pero  list_display_links  te  permite  cambiar  cuales  columnas  se  vinculan.  Establece 
list_display_links  a una  lista  o tupla  de  nombres  de  campo  (en  el  mismo  formato  que 
list_display)  para  vincularlos. 

list_display_links  puede  especificar  uno  o varios  nombres  de  campo.  Mientras  los 
nombres  de  campo  aparezcan  en  list_display,  a Django  no  le  preocupa  si  los  campos 
vinculados  son  muchos  o pocos.  El  unico  requerimiento  es  que  si  quieres  usar 
list_display_links,  debes  definir  list_display. 

En  este  ejemplo,  los  campos  nombre  y apellido  seran  vinculados  a la  pagina  de  la 
lista  de  cambios: 

class  Persona(models. Model): 


class  Admin: 

list  display  = ('nombre',  'apellido',  'fecha_cumpleanos') 

Mst  display  links  = ('nombre',  'apellido') 

En  este  ejemplo,  la  lista  de  cambios  no  tiene  links: 

class  PersonaAdmin(admin.ModelAdmin): 
list_display  = ('nombre',  'apellido') 
list_display_links  = \lone 

Finalmente,  observa  que  para  usar  list_display_links,  debes  definir  tambien 
list_display. 

list_filter 

Establece  list_filter  para  activar  los  filtros  en  la  barra  lateral  derecha  de  la  pagina  de  la 
lista  de  cambios  en  la  interfaz  de  administration.  Debe  ser  una  lista  de  nombres  de 
campo,  y cada  campo  especificado  debe  ser  de  alguno  de  los  tipos  BooleanField, 
DateField,  DateTimeField,  o ForeignKey. 

Este  ejemplo,  tornado  del  modelo  django.contrib.auth. models. User  muestra  como 
trabajan  ambos,  list_display  y list_filter: 

class  User(models. Model): 


class  Admin: 

list  display  = ('username',  'email',  'nombre',  'apellido',  ’is_staff) 
list_filter  = ('is_staff,  'is_superuser') 

ModelAdmin.list_per_page 

list_per_page 

Establece  list_per_page  para  controlar  cuantos  items  aparecen  en  cada  pagina  de  la 
lista  de  cambios  del  administrador.  Por  omision,  este  valor  se  establece  en  100. 

list_select_related 

Establece  list_select_related  para  indicarle  a Django  que  use  select_related()  al 
recuperar  la  lista  de  objetos  de  la  pagina  de  la  lista  de  cambios  del  administrador. 
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Esto  puede  ahorrarte  una  cantidad  de  consultas  a la  base  de  datos  si  estas  utilizando 
objetos  relacionados  en  la  lista  de  cambios  que  muestra  el  administrador. 

El  valor  debe  ser  True  o False.  Por  omision  es  False,  salvo  que  uno  de  los  campos 
list_display  sea  una  ForeignKey. 

Para  mas  detalles  sobre  select_related(),  ver  Apendice  C. 

ordering 

Establece  ordering  para  especilicar  como  deben  ordenarse  los  objetos  en  la  pagina  de 
la  lista  de  cambios  del  administrador.  Esto  debe  ser  una  lista  o tupla  en  el  mismo 
formato  que  el  parametro  ordering  del  modelo. 

Si  no  esta  definido,  la  interfaz  de  administration  de  Django  usara  el  ordenamiento 
por  omision  del  modelo. 

save_as 

Establece  save_as  a True  para  habilitar  la  caracteristica  “save  as”  en  los  formularios 
de  cambios  del  administrador. 

Normalmente,  los  objetos  tienen  tres  opciones  al  guardar:  “Save”,  “Save  and 
continue  editing”  y “Save  and  add  another”.  Si  save_as  es  True,  “Save  and  add 
another”  sera  reemplazado  por  un  boton  “Save  as”. 

“Save  as”  significa  que  el  objeto  sera  guardado  como  un  objeto  nuevo  (con  un 
identificador  nuevo),  en  lugar  del  objeto  viejo. 

Por  omision,  save_as  es  False. 

save_on_top 

Establece  save_on_top  para  agregar  botones  de  guardado  a lo  largo  del  encabezado 
de  tus  formularios  de  cambios  del  administrador. 

Normalmente,  los  botones  de  guardado  aparecen  solamente  al  pie  de  los 
formularios.  Si  estableces  save_on_top,  los  botones  apareceran  en  el  encabezado  y al 
pie  del  formulario. 

Por  omision,  save_on_top  es  False. 

search_fields 

Establece  search_fields  para  habilitar  un  cuadro  de  busqueda  en  la  pagina  de  la  lista 
de  cambios  del  administrador.  Debe  ser  una  lista  de  nombres  de  campo  que  se 
utilizara  para  la  busqueda  cuando  alguien  envie  una  consulta  en  ese  cuadro  de  texto. 

Estos  campos  deben  ser  de  alguna  tipo  de  campo  de  texto,  como  CharField  o 
TextField. 

Tambien  puedes  realizar  una  busqueda  relacionada  sobre  una  relation  ForeignKey 
con  la  notation  de  busqueda  de  la  API: 

class  Empleado(models. Model): 

departmento  = models. ForeignKey(Departmento) 


class  Admin: 

search_fields  = ['departamento'] 

Cuando  alguien  hace  una  busqueda  en  el  cuadro  de  busqueda  del  administrador, 
Django  divide  la  consulta  de  busqueda  en  palabras  y retorna  todos  los  objetos  que 
contengan  alguna  de  las  palabras,  sin  distinguir  mayusculas  y minusculas,  donde 
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cada  palabra  debe  estar  en  al  menos  uno  de  los  searchjields.  Por  ejemplo,  si 
searchjields  es  ['nombre',  'apellido']  y un  usuario  busca  john  lennon,  Django  hara  el 
equivalente  a esta  clausula  WHERE  en  SQL: 

WHERE  (nombre  ILIKE  '%john%'  OR  apellido  ILIKE  '%john%') 

AND  (nombre  ILIKE  '%lennon%'  OR  apellido  ILIKE  '%lennon%') 


Para  busquedas  mas  rapidas  y/o  mas  restrictivas,  agrega  como  prefijo  al  nombre 
de  campo  un  operador  como  se  muestra  en  la  Tabla  A-7. 


Operador  Significado 


A Coincide  al  principio  del  campo.  Por  ejemplo,  si  search_fields  es 

['Anombre',  'Aapellido'],  y un  usuario  busca  john  lennon,  Django  hara  el 
equivalente  a esta  clausula  WHERE  en  SQL: 

WHERE  (nombre  ILIKE  'john%'  OR  apellido  ILIKE  'john%') 

AND  (nombre  ILIKE  'lennon%'  OR  apellido  ILIKE  'lennon%') 

Esta  consul ta  es  mas  eficiente  que  la  consul ta  '%john%',  dado  que  la 
base  de  datos  solo  necesita  examinar  el  principio  de  una  columna  de 
datos,  en  lugar  de  buscar  a traves  de  todos  los  datos  de  la  columna. 
Ademas,  si  la  columna  tiene  un  indice,  algunas  bases  de  datos  pueden 
permitir  el  uso  del  indice  para  esta  consulta,  a pesar  de  que  sea  una 
consulta  LIKE. 

= Coincide  exactamente,  sin  distinguir  mayusculas  y minusculas.  Por 

ejemplo,  si  search_fields  es  ['=nombre',  '=apellido']  y un  usuario  busca 
john  lennon,  Django  hara  el  equivalente  a esta  clausula  WHERE  en  SQL: 

WHERE  (nombre  ILIKE  'john'  OR  apellido  ILIKE  'john') 

AND  (nombre  ILIKE  'lennon'  OR  apellido  ILIKE  'lennon') 

Observa  que  la  entrada  de  la  consulta  se  divide  por  los  espacios,  por  lo 
cual  actualmente  no  es  posible  hacer  una  busqueda  de  todos  los  registros 
en  los  cuales  nombre  es  exactamente  'john  winston'  (con  un  espacio  en 
el  medio). 

@ Realiza  una  busqueda  en  todo  el  texto.  Es  similar  al  metodo  de  busqueda 

predeterminado,  pero  usa  un  indice.  Actualmente  solo  esta  disponible 
para  MySQL. 


Tabla  A7  Operadores  Permitidos  en  search_fields 
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Referenda  de  la  API  de  base 

de  datos 

La  API  de  base  de  datos  de  Django  es  la  otra  mitad  de  la  API  de  modelos  discutido 
en  el  apendice  A Una  vez  que  hayas  definido  un  modelo,  usaras  esta  API  en  cualquier 
momenta  que  necesites  acceder  a la  base  de  datos.  A lo  largo  de  todos  estos 
capitulos,  has  visto  ejemplos  del  uso  de  esta  API;  este  apendice  explica  las  distintas 
opciones  detalladamente. 

De  manera  similar  a lo  que  ocurre  con  las  APIs  de  los  modelos  descritos  en  el 
apendice  anterior,  estas  APIs  son  considerados  muy  estables,  aunque  los 
desarrolladores  de  Django  constantemente  anaden  nuevos  atajos  y conveniencias.  Es 
buena  idea  consultar  siempre  la  documentation  en  linea  mas  actual  que  esta 
disponible  en:  (§)  http://www.djangoproject.com/documentation/. 

A lo  largo  de  este  apendice,  vamos  a hacer  referencia  a los  siguientes  modelos,  los 
cuales  pueden  formar  una  simple  aplicacion  de  un  blog: 


blog/models. py 


from  django.db  import  models 

class  Blog(models. Model): 

nombre  = models. CharField(max_length=100) 
etiqueta  = models. TextField() 

def str (self):  # Unicode on  Python  2 

return  self.nombre 

class  Autor(models. Model): 
nombre  = models.  CharField(max_length=50) 
email  = models. EmailField(blank=  le) 

def str (self):  # Unicode on  Python  2 

return  self.nombre 

class  Entrada(models. Model): 
blog  = models. ForeignKey(Blog) 
titulo  = models.  CharField(max_length=255) 
texto  = models. TextField() 
fecha_publicacion  = models. DateField() 
autores  = models. ManyToManyField(Autor) 
n_comentarios  = models. lntegerField(blank=  , null=  ue) 
rating  = models. lntegerField(blank=  , null=  ) 

def str (self):  # Unicode on  Python  2 

return  self.titulo 


422 


APENDICE  B LA  API  DE  BASE  DE  DATOS 


Creando  Objetos 

Para  crear  un  objeto,  crea  una  instancia  de  la  clase  modelo  usando  argumentos  de 
palabra  clave  y luego  llama  a save()  para  grabarlo  en  la  base  de  datos: 

»>  from  blog. models  import  Blog 

»>  b = Blog(nombre=’Beatles  Blog’,  etiqueta- Las  ultimos  novedades  de  los  beatles.’) 
»>  b.save() 

Esto,  detras  de  escena,  ejecuta  una  sentencia  SQL  INSERT.  Django  no  accede  a la 
base  de  datos  hasta  que  tu  explicitamente  invoques  a save(). 

El  metodo  save()  no  retorna  nada. 

Para  crear  un  objeto  y grabarlo  todo  en  un  paso  revisa  el  metodo  create  de  la  clase 
Manager  que  describiremos  en  breve. 

^Que  pasa  cuando  grabas  un  objeto? 

Cuando  grabas  un  objeto,  Django  realiza  los  siguientes  pasos: 

1.  Emite  una  serial  pre_save:  Se  envia  una  notification 

django.db. models. signals.pre_save  informando  que  un  objeto  esta  a punto  de 
ser  grabado,  permitiendole  a cualquier  funcion  estar  atenta  ante  esta  serial 
para  tomar  ciertas  acciones  para  requisitos  particulares. 

2.  Pre-procesar  los  datos:  Se  le  solicita  a cada  campo  del  objeto  implementar 
cualquier  modification  automatizada  de  datos  que  pudiera  necesitar  realizar. 

La  mayorfa  de  los  campos  no  realizan  pre-procesamiento  - los  datos  del 
campo  se  guardan  tal  como  estan.  Solo  se  usa  pre-procesamiento  en  campos 
que  tienen  un  comportamiento  especial,  como  campos  de  archivo. 

3.  Preparar  los  datos  para  la  base  de  datos:  Se  le  solicita  a cada  campo  que 
provea  su  valor  actual  en  un  tipo  de  dato  que  puede  ser  grabado  en  la  base  de 
datos. 

La  mayoria  de  los  campos  no  requieren  preparation  de  los  datos.  Los  tipos  de 
datos  simples,  como  enteros  y cadenas,  estan  “listos  para  escribir”  como  un 
objeto  de  Python.  Sin  embargo,  tipo  de  datos  mas  complejos  requieren  a 
menudo  alguna  modification. 

Por  ejemplo  la  clase  DateField usa  un  objeto  datetime  Python  para  almacenar 
datos.  Las  bases  de  datos  no  almacenan  objetos  datetime,  de  manera  que  el 
valor  del  campo  debe  ser  convertido  en  una  cadena  de  fecha  que  cumpla  con 
la  norma  ISO  correspondiente  para  la  insertion  en  la  base  de  datos. 

4.  Insertar  los  datos  en  la  base:  Los  datos  pre-procesados  y preparados  son 
entonces  incorporados  en  una  sentencia  SQL  para  su  insertion  en  la  base  de 
datos. 

5.  Emitir  una  serial  post_save:  Como  con  la  serial  pre_save,  esta  es  utilizada 
para  proporcionar  notification  de  que  un  objeto  ha  sido  grabado 
satisfactoriamente. 
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Claves  primarias  autoincrementales 

Por  conveniencia,  a cada  modelo  se  le  da  una  clave  primaria  autoincremental 
llamada  id  a menos  que  explicitamente  especifiques  primary_key=True  en  el  campo 
(ver  la  section  titulada  “ AutoField’  en  el  Apendice  B) . 

Si  tu  modelo  tiene  un  AutoField,  ese  valor  incrementado  automaticamente  sera 
calculado  y grabado  como  un  atributo  de  tu  objeto  la  primera  vez  que  llames  a save(): 

»>  b2  = Blog(nombre=’Charlas  Cheddar’,  etiqueta=’Pensamientos  sobre  quesos.’) 

»>  b2.id  # Devuelve  “None“,  porque  b no  tiene  un  ID. 

None 

»>  b2.save() 

»>  b2.id  # Devuelve  el  ID  de  el  nuevo  objeto. 

2 


No  hay  forma  de  saber  cual  sera  el  valor  de  un  identificador  (ID)  antes  que  llames 
a el  metodo  save()  esto  se  debe  a que  ese  valor  es  calculado  por  la  base  de  datos,  no 
por  Django. 

Si  un  modelo  tiene  un  AutoField  pero  quieres  definir  el  identificador  de  un  nuevo 
objeto  explicitamente  cuando  grabas,  solo  definelo  explicitamente  antes  de  grabarlo 
en  vez  de  confiar  en  la  asignacion  automatica  de  valor  del  identificador: 

»>  b3  = Blog(id=3,  nombre-Charlas  Cheddar’,  etiqueta-Pensamientos  sobre 
quesos.) 

»>  b3.id 

3 

»>  b3.save() 

»>  b3.id 

3 


Si  asignas  manualmente  valores  de  claves  primarias  autoincrementales  jAsegurate 
de  no  usar  un  valor  de  clave  primaria  que  ya  existe!  Si  creas  un  objeto  con  un  valor 
explicito  de  clave  primaria  que  ya  existe  en  la  base  de  datos,  Django  asumira  que 
estas  cambiando  el  registro  existente  en  vez  de  crear  uno  nuevo. 

Dado  el  ejemplo  precedente  de  blog  'Charlas  Cheddar',  este  ejemplo 
sobrescribiria  el  registro  previo  en  la  base  de  datos: 

»>  b4  = Blog(  =3,  nombre-blog  ’,  etiqueta- Todo  menos  quesos. ) 

»>  b4.save()  # jSobrescribe  el  anterior  blog  con  ID=3! 

El  especilicar  explicitamente  valores  de  claves  primarias  autoincrementales  es 
mas  util  cuando  se  estan  grabando  objetos  en  lotes,  cuando  estas  seguro  de  que  no 
tendras  colisiones  de  claves  primarias. 

Grabando  cambios  de  objetos 


Para  grabar  los  cambios  hechos  a un  objeto  que  existe  en  la  base  de  datos,  usa  saveO- 
Dada  la  instancia  de  Blog  b4  que  ya  ha  sido  grabada  en  la  base  de  datos,  este 
ejemplo  cambia  su  nombre  y actualiza  su  registro  en  la  base: 

»>  b4. nombre  = ’El  mejor  Blog’ 

»>  b4.save() 

»>  b4 
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<Blog:  El  mejor  Blog> 

Detras  de  escena,  esto  ejecuta  una  sentencia  SQL  UPDATE.  De  nuevo:  Django  no 
accede  a la  base  de  datos  hasta  que  llamas  explicitamente  a saved. 


Como  sabe  django  cuando  usar  UPDATE  y cuando  usar  INSERT? 


Habras  notado  que  los  objetos  de  base  de  datos  de  Django  usan  el  mismo  metodo 
saveO  para  crear  y cambiar  objetos.  Django  abstrae  la  necesidad  de  usar  sentencias 
SQL  INSERT  o UPDATE.  Especificamente,  cuando  llamas  a saveO,  Django  sigue  este 
algoritmo: 

■ Si  el  atributo  clave  primaria  del  objeto  tiene  asignado  un  valor  que  evalua 
True  (esto  es,  un  valor  distinto  a None  o a la  cadena  vacia)  Django  ejecuta 
una  consulta  SELECT  para  determinar  si  existe  un  registro  con  la  clave 
primaria  especificada. 

■ Si  el  registro  con  la  clave  primaria  especificada  ya  existe,  Django  ejecuta  una 
consulta  UPDATE. 

■ Si  el  atributo  clave  primaria  del  objeto  no  tiene  valor  o si  lo  tiene  pero  no 
existe  un  registro,  Django  ejecuta  un  INSERT. 

Debido  a esto,  debes  tener  cuidado  de  no  especificar  un  valor  explicito  para  una 
clave  primaria  cuando  grabas  nuevos  objetos  si  es  que  no  puedes  garantizar  que  el 
valor  de  clave  primaria  esta  disponible  para  ser  usado. 


La  actualization  de  campos  ForeignKey  funciona  exactamente  de  la  misma  forma; 
simplemente  asigna  un  objeto  del  tipo  correcto  al  campo  en  cuestion: 

»>  from  blog. models  import  Autor,  Entrada 
»>  joe  = Autor.  objects.  create(nombre="Joe") 

»>  Entrada. autor  =joe 
»>  joe.saveQ 

Django  se  quejara  si  intentas  asignar  un  objeto  del  tipo  incorrecto. 

Recuperando  objetos 

A traves  del  libro  has  visto  como  se  recuperan  objetos  usando  codigo  como  el 
siguiente: 

»>  from  blog. models  import  Autor 

»>  blogs  = Autor. objects. filter(nombre contains-'Joe") 

Hay  bastantes  partes  moviles  detras  de  escena  aqui:  cuando  recuperas  objetos  de 
la  base  de  datos,  estas  construyendo  realmente  un  QuerySet  (consulta)  usando  el 
Manager  del  modelo.  Este  QuerySet  sabe  como  ejecutar  SQL  y retornar  los  objetos 
solicitados. 

El  Apendice  A trato  ambos  objetos  desde  el  punto  de  vista  de  la  definition  del 
modelo;  ahora  vamos  a ver  como  funcionan. 

Un  QuerySet  representa  una  coleccion  de  objetos  de  tu  base  de  datos.  Puede  tener 
cero,  uno,  o muchos  filtros  - criterios  que  limitan  la  coleccion  basados  en  parametros 
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provistos.  En  terminos  de  SQL  un  QuerySet  se  compara  a una  declaration  SELECT  y 
un  filtro  es  una  clausula  de  limitation  como  por  ejemplo  WHERE  o LIMIT. 

Consigues  un  QuerySet  usando  el  Manager  del  modelo.  Cada  modelo  tiene  por  lo 
menos  un  Manager  y tiene,  por  omision,  el  nombre  objects.  Accede  al  mismo 
directamente  a traves  de  la  clase  del  modelo,  asi: 

»>  Blog. objects 

<django.db. models. manager.Manager  object  at  0xl37d00d> 

Los  Managers  solo  son  accesibles  a traves  de  las  clases  de  los  modelos,  en  vez 
desde  una  instancia  de  un  modelo,  para  asi  hacer  cumplir  con  la  separation  entre  las 
operaciones  a “nivel  de  tabla”  y las  operaciones  a “nivel  de  registro”: 

»>  b = Blog(nombre- Foo’,  etiqueta- Bar ) 

»>  b. objects 

Traceback  (most  recent  call  last): 

File  "<stdin>",  line  1,  in  <module> 

Attribute  Error:  "Manager  isn’t  accessible  via  % instances" " type... 

El  Manager  es  la  principal  fuente  de  QuerySets  para  un  modelo.  Actua  como  un 
QuerySet  “raiz”  que  describe  todos  los  objetos  de  la  tabla  de  base  de  datos  del 
modelo.  Por  ejemplo,  Blog.objects  es  el  QuerySets  inicial  que  contiene  todos  los 
objetos  Blog  en  la  base  de  datos. 

Cacheo  y QuerySets 

Cada  QuerySet  contiene  un  cache,  para  minimizar  el  acceso  a la  base  de  datos.  Es 
importante  entender  como  funciona,  para  escribir  codigo  mas  eficiente. 

En  un  QuerySet  recien  creado,  el  cache  esta  vacio.  La  primera  vez  que  un  QuerySet 
es  evaluado  - y,  por  lo  tanto,  ocurre  un  acceso  a la  base  de  datos  - Django  graba  el 
resultado  de  la  consulta  en  el  cache  del  QuerySet  y retorna  los  resultados  que  han 
sido  solicitados  explicitamente  (por  ejemplo,  el  siguiente  elemento,  si  se  esta 
iterando  sobre  el  QuerySet). 

Evaluaciones  subsecuentes  del  QuerySet  re-usan  los  resultados  alojados  en  el 
cache. 

Ten  presente  este  comportamiento  de  caching,  porque  puede  morderte  si  no  usas 
tus  QuerySets  correctamente.  Por  ejemplo,  lo  siguiente  creara  dos  QuerySets,  los 
evaluara,  y los  descartara: 

»>  print  ([e.titulo  for  e in  Entrada.objects.all()]) 

»>  print  ([e.fecha_publicacion  for  e in  Entrada.objects.all()]) 

Eso  significa  que  la  consulta  sera  ejecutada  dos  veces  en  la  base  de  datos, 
duplicando  la  carga  sobre  la  misma.  Tambien  existe  una  posibilidad  de  que  las  dos 
listas  pudieran  no  incluir  los  mismos  registros  de  la  base  de  datos,  porque  se  podria 
haber  agregado  o borrado  un  Entrada  durante  el  pequenisimo  periodo  de  tiempo 
entre  ambas  peticiones. 

Para  evitar  este  problema,  simplemente  graba  el  QuerySet  y re-usalo: 

»>  from  blog. models  import  Autor 
»>  queryset  = Autor. objects. all() 

»>  print  ([p. nombre  for  p in  queryset])  # Evalua  el  query  set. 

»>  print  ([p. email  for  p in  queryset])  # Reusa  la  cache  de  la  evaluation  anterior. 
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Filtrando  objetos 

La  manera  mas  simple  de  recuperar  objetos  de  una  tabla  es  conseguirlos  todos.  Para 
hacer  esto,  usa  el  metodo  all()  en  un  Manager: 

»>  from  blog. models  import  Entrada 
»>  Entrada. objects. all() 

El  metodo  all()  retorna  un  QuerySet  de  todos  los  objetos  de  la  base  de  datos. 

Sin  embargo,  usualmente  solo  necesitaras  seleccionar  un  subconjunto  del 
conjunto  completo  de  objetos.  Para  crear  tal  subconjunto,  refinas  el  QuerySet  inicial, 
anadiendo  condiciones  con  filtros.  Usualmente  haras  esto  usando  los  metodos  filter() 
y/o  exclude!): 

»>  si2014  = Entrada. objects. filter(fecha_publicacion year=2014) 

»>  no2014  = Entrada. objects. exclude(fecha_publicacion year=2014) 

Tanto  filter!)  como  exclude!)  toman  argumentos  de  patrones  de  busqueda,  los 
cuales  se  discutiran  detalladamente  en  breve. 

Encadenando  filtros 

El  resultado  de  refinar  un  QuerySet  es  otro  QuerySet  asi  que  es  posible  enlazar 
refinamientos,  por  ejemplo: 

>»  import  datetime 

»>  qs  = Entrada.objects.filter(titulo startswith- Que’) 

»>  qs  = qs.exclude(fecha_publicacion gte=datetime. datetime. now()) 

»>  qs  = qs.filter(fecha_publicacion gte=datetime.datetime(2005, 1, 1)) 

Esto  toma  el  QuerySet  inicial  de  todas  las  entradas  en  la  base  de  datos,  agrega  un 
filtro,  luego  una  exclusion,  y luego  otro  filtro.  El  resultado  final  es  un  QuerySet 
conteniendo  todas  las  entradas  con  un  titulo  que  empieza  con  “What”  que  fueron 
publicadas  entre  Enero  1,  2005,  y el  dia  actual. 

Es  importante  precisar  aqui  que  los  QuerySet  son  perezosos  - el  acto  de  crear  un 
QuerySet  no  implica  ninguna  actividad  en  la  base  de  datos.  De  hecho,  las  tres  lineas 
precedentes  no  hacen  ninguna  llamada  a la  base  de  datos;  puedes  enlazar/encadenar 
filtros  todo  el  dia  y Django  no  ejecutara  realmente  la  consulta  hasta  que  el  QuerySet 
sea  evaluado. 

Puedes  evaluar  un  QuerySet  en  cualquiera  de  las  siguientes  formas: 

• Iterando:  Un  QuerySet  es  iterable,  y ejecuta  su  consulta  en  la  base  de  datos  la 
primera  vez  que  iteras  sobre  el.  Por  ejemplo,  el  siguiente  QuerySet  no  es 
evaluado  hasta  que  se  iterado  sobre  el  en  el  bucle  for: 

»>  qs  = Entrada. objects. filter(fecha_publicacion year=2006) 

»>  qs  = qs.filter(titulo icontains="biN") 

»>  for  e in  qs: 

»>  print  (e. titulo) 

Esto  imprime  todos  los  titulos  desde  el  2006  que  contienen  “bill”  pero  genera 
solo  un  acceso  a la  base  de  datos. 
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• Imprimiendo:  Un  QuerySet  es  evaluado  cuando  ejecutas  repr()  sobre  el 
mismo.  Esto  es  por  conveniencia  en  el  interprete  interactivo  Python,  as! 
puedes  ver  inmediatamente  tus  resultados  cuando  usas  el  API 
interactivamente. 

• Rebanado:  Segun  lo  explicado  en  la  proxima  section  “Limitando  QuerySets”, 
un  QuerySet  puede  ser  rebanado  usando  la  sintaxis  de  rebanado  de  arreglos 
de  Python.  Usualmente  el  rebanar  un  QuerySet  retorna  otro  QuerySet  (no 
evaluado),  pero  Django  ejecutara  la  consulta  a la  base  de  datos  si  usas  el 
parametro  “step”  de  la  sintaxis  de  rebanado. 

• Convirtiendo  a una  lista:  Puedes  forzar  la  evaluation  de  un  QuerySet 
ejecutando  list()  sobre  el  mismo,  por  ejemplo: 

»>  entradajist  = Nst(Entrada.objects.allQ) 


Sin  embargo,  quedas  advertido  de  que  esto  podria  significar  un  gran  impacto  en  la 
memoria  porque  Django  cargara  cada  elemento  de  la  lista  en  memoria.  En  cambio,  el 
iterar  sobre  un  QuerySet  sacara  ventaja  de  tu  base  de  datos  para  cargar  datos  e 
inicializar  objetos  solo  a medida  que  vas  necesitando  los  mismos. 


LOS  QUERYSETS  FILTRADOS  SON  UNICOS 


Cada  vez  que  refinas  un  QuerySet  obtienes  un  nuevo  QuerySet  que  no  esta  de 
ninguna  manera  atado  al  QuerySet'  anterior.  Cada  refinamiento  crea  un  QuerySet 
separado  y distinto  que  puede  ser  almacenado,  usado  y re-usado: 

»>  ql  = Entrada. objects. filter(titulo startswith="Que") 

»>  q2  = ql.exclude(fecha_publicacion gte=datetime.now()) 

»>  q3  = ql.filter(fecha_publicacion gte=datetime.now()) 

Estos  tres  QuerySets  son  separados.  El  primero  es  un  QuerySet  base  que  contiene 
todas  las  entradas  que  contienen  un  titulo  que  empieza  con  “What”.  El  segundo  es 
un  sub-conjunto  del  primero,  con  un  criterio  adicional  que  excluye  los  registros 
cuyo  fecha_publicacion  es  mayor  que  el  dia  de  hoy.  El  tercero  es  un  sub-conjunto 
del  primero,  con  un  criterio  adicional  que  selecciona  solo  los  registros  cuyo 
fecha_publicacion  es  mayor  que  el  dia  de  hoy.  El  QuerySet  inicial  (ql)  no  es  afectado 
por  el  proceso  de  refinamiento. 


Limitando  QuerySets 


Usa  la  sintaxis  de  rebanado  de  arreglos  de  Python  para  limitar  tu  QuerySet  a un  cierto 
numero  de  resultados.  Esto  es  equivalente  a las  clausulas  de  SQL  de  LIMIT  y OFFSET. 
Por  ejemplo,  esto  retorna  las  primeras  cinco  entradas  (LIMIT  5): 

»>  Entrada.objects.all()[:5] 

Esto  retorna  las  entradas  desde  la  sexta  hasta  la  decima  (OFFSET  5 LIMIT  5): 


»>  Entrada. objects. all()[5:10] 
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Generalmente,  el  rebanar  un  QuerySet  retorna  un  nuevo  QuerySet  - no  evalua  la 
consulta.  Una  exception  es  si  usas  el  parametro  “step”  de  la  sintaxis  de  rebanado  de 
Python.  Por  ejemplo,  esto  realmente  ejecutaria  la  consulta  con  el  objetivo  de  retornar 
una  lista,  objeto  de  por  medio  de  los  primeros  diez: 

>»  Entrada. objects. all()[:10:2] 

Para  recuperar  un  solo  objeto  en  vez  de  una  lista  (por  ej.  SELECT  foo  FROM  bar 
LIMIT  1)  usa  un  simple  indice  en  vez  de  un  rebanado.  Por  ejemplo,  esto  retorna  el 
primer  Entrada  en  la  base  de  datos,  despues  de  ordenar  las  entradas  alfabeticamente 
por  tltulo: 

»>  Entrada. objects. order_by(’titulo  )[0] 

y es  equivalente  a lo  siguiente: 

»>  Entrada.objects.order_by(’titulo’)[0:l].get() 

Nota,  sin  embargo,  que  el  primero  de  estos  generara  IndexError  mientras  el 
segundo  generara  DoesNotExist  si  ninguno  de  los  objetos  coincide  con  el  criterio 
dado. 


Metodos  de  consulta  que  retoman  nuevos  QuerySets 

Django  provee  una  variedad  de  metodos  de  refinamiento  de  QuerySet  que  modifican 
ya  sea  los  tipos  de  resultados  retornados  por  el  QuerySet  o la  forma  como  se  ejecuta 
su  consulta  SQL. 

Estos  metodos  se  describen  en  las  secciones  que  siguen.  Algunos  de  estos 
metodos  reciben  argumentos  de  patrones  de  busqueda,  los  cuales  se  discuten  en 
detalle  mas  adelante. 

filter(**lookup) 

Retorna  un  nuevo  QuerySet  conteniendo  objetos  que  son  iguales  a los  parametros  de 
busqueda  provistos. 

exclude(**kwargs) 

Retorna  un  nuevo  QuerySet  conteniendo  objetos  que  no  son  iguales  a los  parametros 
de  busqueda  provistos. 

order_by(*fields) 

Por  omision,  los  resultados  retornados  por  un  QuerySet  estan  ordenados  por  la  tupla 
de  ordenamiento  indicada  por  la  option  ordering  en  los  metadatas  del  modelo. 

Puedes  sobrescribir  esto  para  una  consulta  particular  usando  el  metodo 
orderJbyO: 

»>Entrada. objects. filter(fecha_publicacion year=2005).order_by( 

’-fecha_publicacion’,  ’titulo’) 

Este  resultado  sera  ordenado  por  fecha_publicacion  de  forma  descendente,  luego 
por  titulo  de  forma  ascendente.  El  signo  negativo  en  frente  de  "-fecha_publicacion" 
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indica  orden  descendiente.  Si  el  - esta  ausente  se  asume  un  orden  ascendente.  Para 
ordenar  aleatoriamente,  usa  asi: 

>»  Entrada.objects.order_by(’?’) 

distinct() 

Retorna  un  nuevo  QuerySet  que  usa  SELECT  DISTINCT  en  su  consulta  SQL.  Esto 
elimina  filas  duplicadas  en  el  resultado  de  la  misma. 

Por  omision,  un  QuerySet  no  eliminara  filas  duplicadas.  En  la  practica  esto 
raramente  es  un  problema  porque  consultas  simples  como  Blog.objects.all()  no 
introducen  la  posibilidad  de  registros  duplicados. 

Sin  embargo,  si  tu  consulta  abarca  multiples  tablas,  es  posible  obtener  resultados 
duplicados  cuando  un  QuerySet  es  evaluado.  Esos  son  los  casos  en  los  que  usarias 
distinct  0- 

values(*fields) 

Retorna  un  QuerySet  especial  que  evalua  a una  lista  de  diccionarios  en  lugar  de 
objetos  instancia  de  modelo.  Cada  uno  de  esos  diccionarios  representa  un  objeto, 
con  las  las  claves  en  correspondencia  con  el  nombre  de  los  atributos  de  los  objetos 
modelo: 

# Esta  lista  contiene  un  objeto  Blog. 

»>  Blog. objects. filter(nombre startswith- Beatles') 

[Beatles  Blog] 

# Esta  lista  contiene  un  diccionario. 

»>  Blog. objects. filter(nombre startswith- Beatles'). values() 

[{'id':  1,  'nombre':  'Beatles  Blog’,  ’etiqueta’:  'Las  ultimas  novedades  de  los  Beatles.'}] 

valuesO  puede  recibir  argumentos  posicionales  opcionales,  *campos,  los  cuales 
especifican  los  nombres  de  campos  a los  cuales  debe  limitarse  el  SELECT.  Si 
especificas  los  campos,  cada  diccionario  contendra  solamente  las  claves /valores  de 
campos  para  los  campos  que  especifiques. 

Si  no  especificas  los  campos,  cada  diccionario  contendra  una  clave  y un  valor  para 
todos  los  campos  en  la  table  de  base  de  datos: 

»>  Blog. objects. values() 

[{'id':  1,  'nombre':  'Beatles  Blog’,  'etiqueta':  'All  the  latest  Beatles  news.’}], 

»>  Blog. objects. values(’id’,  'nombre') 

[{'id':  1,  'nombre':  'Beatles  Blog’}] 

Este  metodo  es  util  cuando  sabes  de  antemano  que  solo  vas  a necesitar  valores  de 
un  pequeno  numero  de  los  campos  disponibles  y no  necesitaras  la  funcionalidad  de 
un  objeto  instancia  de  modelo.  Es  mas  eficiente  el  seleccionar  solamente  los  campos 
que  necesitas  usar. 

dates(field,  kind,  order) 

Retorna  un  QuerySet  especial  que  evalua  a una  lista  de  objetos  datetime.datetime 
que  representan  todas  las  fechas  disponibles  de  un  cierto  tipo  en  el  contenido  de  la 
QuerySet. 
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El  argumento  campo  debe  ser  el  nombre  de  un  DateField  o de  un  DateTimeField 
de  tu  modelo.  El  argumento  tipo  debe  ser  ya  sea  year,  month  o day.  Cada  objeto 
datetime. datetime  en  la  lista  de  resultados  es  truncado  de  acuerdo  al  tipo  provisto: 

• 'year":  retorna  una  lista  de  todos  los  valores  de  anos  distintos  entre  si  para  el 
campo. 

• "month":  retorna  una  lista  de  todos  los  valores  de  anos/mes  distintos  entre  si 
para  el  campo. 

• "day”:  retorna  una  lista  de  todos  los  valores  de  anos/mes/dia  distintos  entre 
si  para  el  campo. 

• “orden”:  cuyo  valor  por  omision  es  ’ASC’,  debe  ser  ’ASC  o 'DESC.  El  mismo 
especifica  como  ordenar  los  resultados. 

Aqui  tenemos  algunos  ejemplos: 

»>  Entrada. objects. dates(’fecha_publicacion’,  ’year’) 

[datetime. datetime(2005,  1,  1)] 

»>  Entrada. objects. dates(’fecha_publicacion’,  ’month’) 

[datetime. datetime(2005,  2,  1),  datetime. datetime(2005,  3,  1)] 

»>  Entrada. objects. dates(’fecha_publicacion’,  ’day  ) 

[datetime. datetime(2005,  2,  20),  datetime. datetime(2005,  3,  20)] 

»>  Entrada. objects. dates(’fecha_publicacion’,  ’day',  order- DESC’) 

[datetime. datetime(2005,  3,  20),  datetime. datetime(2005,  2,  20)] 

»>  Entrada. objects. filter(titulo contains- Lennon’). dates(’fecha_publicacion’,  ’day’) 

[datetime. datetime(2005,  3,  20)] 

select_related() 

Retorna  un  QuerySet  que  seguira  automaticamente  relaciones  de  clave  foranea, 
seleccionando  esos  datos  adicionales  de  objetos  relacionados  cuando  ejecuta  su 
consulta.  Esto  contribuye  a la  mejora  de  rendimiento  que  resulta  en  consultas 
(aveces  mucho)  mas  grandes  pero  significan  que  el  uso  posterior  de  relaciones  de 
clave  foranea  no  requeriran  consultas  a la  base  de  datos. 

Los  siguientes  ejemplos  ilustran  la  diferencia  entre  busquedas  normales  y 
busquedas  select_related(). 

Esta  es  una  busqueda  normal: 

# Consulta  a la  base  de  datos. 

»>  e = Entrada.objects.get(id=l) 

# Consulta  nuevamente  a la  base  de  datos  para  obtener  los  objetos  blog  relacionados. 
»>  b = e.blog 

Esta  es  una  busqueda  select_related: 

# Consulta  a la  base  de  datos. 

»>  e = Entrada.objects.select_related().get(id=l) 
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# No  consulta  la  base  de  datos,  porque  e.blog  ha  sido  precargada  en  la  anterior 
consulta. 

»>  b = e.blog 

select_related()  sigue  claves  foraneas  tan  lejos  como  le  sea  posible.  Si  tienes  los 
siguientes  modelos: 

class  Ciudad(models. Model): 

# ... 

class  Persona(models. Model): 

# ... 

ciudad_natal  = models. ForeignKey(Ciudad) 

class  Libro(models. Model): 

# ... 

autor  = models.  ForeignKey(Persona) 

Entonces  una  llamada  a Lib ro. objects. select_related().get(id=4)  colocara  en  el 
cache  la  Persona  relacionada  y la  Ciudad  relacionada: 

»>b  = Libro. objects. select_related().get(id=4) 

»>  p = b. autor  # No  consulta  la  base  de  datos. 

»>  c = p.ciudad_natal  # No  consulta  la  base  de  datos. 

»>  b = Libro. objects. get(id=4)  # En  este  ejemplo  no  select_related() 

»>  p = b. autor  # Consulta  a la  base  de  datos. 

»>  c = p.ciudad_natal  # Consulta  a la  base  de  datos. 

Nota  que  select_related no  sigue  claves  foraneas  que  tienen  asignado  null=True. 
Usualmente,  el  usar  select_related()  puede  mejorar  muchisimo  el  desempeno 
porque  tu  aplicacion  puede  puede  entonces  evitar  muchas  llamadas  a la  base  de 
datos.  Sin  embargo,  en  siuaciones  con  conjuntos  de  relaciones  profundamente 
anidadas,  select_related()  puede  en  algunos  casos  terminar  siguiendo  “demasiadas” 
relaciones  y puede  generar  consultas  tan  grandes  que  terminan  siendo  lentas. 

extra() 

A veces,  el  lenguaje  de  consulta  de  Django  no  puede  expresar  facilmente  clausulas 
WHERE  complejas.  Para  estos  casos  extremos,  Django  provee  un  modificador  de 
QuerySet  llamado  extraO  - una  forma  de  inyectar  clausulas  especificas  dentro  del 
SQL  generado  por  un  QuerySet. 

Por  definition,  estas  consultas  especiales  pueden  no  ser  portables  entre  los 
distintos  motores  de  bases  de  datos  (debido  a que  estas  escribiendo  codigo  SQL 
explicito)  y violan  el  principio  DRY,  asi  que  deberias  evitarlas  de  ser  posible. 

Se  puede  especificar  uno  o mas  de  params,  select,  where,  o tables.  Ninguno  de  los 
argumentos  es  obligatorio,  pero  deberias  indicar  al  menos  uno. 

El  argumento  select  permite  indicar  campos  adicionales  en  una  clausula  de 
SELECT.  Debe  contener  un  diccionario  que  mapee  nombres  de  atributo  a clausulas 
SQL  que  se  utilizaran  para  calcular  el  atributo  en  cuestion: 

»>  Entrada. objects. extra(select={’is_recent’:  "fecha_publicacion  > ’2006-01-01’"}) 
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Como  resultado,  cada  objeto  Entrada  tendra  en  este  caso  un  atributo  adicional, 
is_recent,  un  booleano  que  representara  si  el  atributo  fecha_publicacion  del  entrada 
es  mayor  que  el  1 de  Enero  de  2006. 

El  siguiente  ejemplo  es  mas  avanzado;  realiza  una  subconsul ta  para  darle  a cada 
objeto  Blog  resultante  un  atributo  entrada_count,  un  entero  que  indica  la  cantidad  de 
objetos  Entrada  asociados  al  blog: 

>»  subq  = ’SELECT  COUNT(*)  FROM  blog_entrada  WHERE  blog_entrada.blog_id  = 
blogblog.id’ 

»>  Blog. objects. extra(select={’entrada_count’:  subq}) 

(En  este  caso  en  particular,  estamos  aprovechando  el  hecho  de  que  la  consulta  ya 
contiene  la  tabla  blog_blog  en  su  clausula  FROM.) 

Tambien  es  posible  definir  clausulas  WHERE  explicitas  - quizas  para  realizar  joins 
implicitos  - usando  el  argumento  where.  Se  puede  agregar  tablas  manualmente  a la 
clausula  FROM  del  SQL  usando  el  argumento  tables. 

Tanto  where  como  tables  reciben  una  lista  de  cadenas.  Todos  los  argumentos  de 
where  son  unidos  con  AND  a cualquier  otro  criterio  de  busqueda: 

»>  Entrada. objects. extra(where=[’id  IN  (3,  4,  5,  20)’]) 

Los  parametros  select  y where  antes  descritos  pueden  utilizar  los  comodines 
normales  para  bases  de  datos  en  Python:  '%s'  para  indicar  parametros  que  deberian 
ser  escapados  automaticamente  por  el  motor  de  la  base  de  datos.  El  argumento 
params  es  una  lista  de  los  parametros  que  seran  utilizados  para  realizar  la 
sustitucion: 

»>  Entrada. objects. extra(where=[’titulo=%s’],  params=[’Lennon’]) 


Siempre  se  debe  utilizar  params  en  vez  de  utilizar  valores  directamente  en  select  o 
where  ya  que  params  asegura  que  los  valores  seran  escapados  correctamente  de 
acuerdo  con  tu  motor  de  base  de  datos  particular. 

Este  es  un  ejemplo  de  lo  que  esta  incorrecto: 

Entrada. objects. extra(where=["titulo=’%s’"  % nombre]) 

Este  es  un  ejemplo  de  lo  que  es  correcto: 

Entrada.objects.extra(where=[’titulo=%s’],  params=[nombre]) 


Metodos  de  QuerySet  que  no  devuelven  un  QuerySet 

Los  metodos  de  QuerySet  que  se  describen  a continuation  evaluan  el  QuerySet  y 
devuelven  algo  que  no  esun  QuerySet  - un  objeto,  un  valor,  o algo  asi. 

get(**lookup) 

Devuelve  el  objeto  que  matchee  el  parametro  de  busqueda  provisto.  El  parametro 
debe  proveerse  de  la  manera  descripta  en  la  section  “Patrones  de  busqueda”.  Este 
metodo  levanta  AssertionError  si  mas  de  un  objecto  concuerda  con  el  patron 
provisto. 

Si  no  se  encuentra  ningun  objeto  que  coincida  con  el  patron  de  busqueda  provisto 
get()  levanta  una  exception  de  DoesNotExist.  Esta  exception  es  un  atributo  de  la 
clase  del  modelo,  por  ejemplo: 
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»>  Entrada.objects.get(id-foo’)  # levanta  Entrada.DoesNotExist 

La  exception  DoesNotExist  hereda  de  la  clase: 
django. core. exceptions. ObjectDoesNotExist,  asi  que  puedes  protegerte  de  multiples 
excepciones  DoesNotExist: 

>»  from  django. core. exceptions  import  ObjectDoesNotExist 
»>  try: 

e = Entrada.objects.get(id=3) 
b = Blog,  objects.  get(id=l) 

...  except  ObjectDoesNotExist: 

...  print  ("La  entrada  o el  blog  no  existen.") 


create(**kwargs) 

Este  metodo  sirve  para  crear  un  objeto  y guardarlo  en  un  mismo  paso.  Te  permite 
abreviar  dos  pasos  comunes: 

»>  p = Persona(first_nombre="Bruce",  last_nombre="Springsteen") 

>»  p.save() 

en  una  sola  linea: 

»>  p = Persona. objects. create(first_nombre="Bruce",  last_nombre="Springsteen") 


get_o  r_c  reate(**  kwa  rg  s) 

Este  metodo  sirve  para  buscar  un  objeto  y crearlo  si  no  existe.  Devuelve  una  tupla 
(object,  created),  donde  object  es  el  objecto  encontrado  o creado,  y created  es  un 
booleano  que  indica  si  el  objeto  fue  creado. 

Esta  pensado  como  un  atajo  para  el  caso  de  uso  tipico  y es  mas  que  nada  util  para 
scripts  de  importation  de  datos,  por  ejemplo: 

try: 

obj  = Persona.objects.get(nombre  = ’John’,  apellido  = ’Lennon’) 
except  Persona. DoesNotExist: 

obj  = Persona(nombre  = ’John',  apellido- Lennon’, 
fecha_nacimiento=  date(1940, 10,  9)) 
obj.save() 

Este  patron  se  vuelve  inmanejable  a medida  que  aumenta  el  numero  de  campos 
en  el  modelo.  El  ejemplo  anterior  puede  ser  escrito  usando  get_or_create  asi: 

obj,  created  = Persona. objects. get_or_create( 
nombre  = ’John’, 
apellido  = ’Lennon’, 

defaults  = {’fecha_nacimiento’:  date(1940, 10,  9)} 

) 


Cualquier  argumento  que  se  le  pase  a get_or_create()  - excepto  el  argumento 
opcional  defaults  - sera  utilizado  en  una  llamada  a get().  Si  se  encuentra  un  objecto, 
get_or_create  devolvera  una  tupla  con  ese  objeto  y False.  Si  no  se  encuentra  un 
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objeto,  get_or_create()  instanciara  y guardara  un  objeto  nuevo,  devolviendo  una 
tupla  con  el  nuevo  objeto  y True.  El  nuevo  objeto  sera  creado  de  acuerdo  con  el 
siguiente  algoritmo: 

defaults  = kwargs.pop(’defaults’,  {}) 

params  = Jict([(k,  v)  for  k,  v in  kwargs.items()  if  ’ ’ not  in  k]) 

params.update(defaults) 
obj  = self.model(**params) 
obj.save() 

Esto  es,  se  comienza  con  los  argumentos  que  no  sean  'defaults'  y que  no 
contengan  doble  guion  bajo  (lo  cual  indicaria  una  busqueda  no  exacta).  Luego  se  le 
agrega  el  contenido  de  defaults,  sobreescribiendo  cualquier  valor  que  ya  estuviera 
asignado,  y se  usa  el  resultado  como  claves  para  el  constructor  del  modelo. 

Si  el  modelo  tiene  un  campo  llamado  defaults  y es  necesario  usarlo  para  una 

busqueda  exacta  en  get_or_create(),  simplemente  hay  que  utilizar  'defaults exact' 

asr: 

Foo. objects. get_or_create( 

defaults exact  = 'bar', 

defaults={’defaults’:  ’baz’} 

) 


count() 

Devuelve  un  entero  representando  el  numero  de  objetos  en  la  base  de  datos  que 
coincidan  con  el  QuerySet.  countQ  nunca  levanta  excepciones.  He  aqui  un  ejemplo: 


# Returns  the  total  number  of  entries  in  the  database. 

»>  Entrada. objects. count() 

4 

# Returns  the  number  of  entries  whose  titulo  contains  'Lennon' 

»>  Entrada. objects. filter(titulo contains- Lennon'). count() 

1 


count 0 en  el  fondo  realiza  un  SELECT  COUNT(*),  asr  que  deberias  siempre  utilizar 
countf)  en  vez  de  cargar  todos  los  registros  en  objetos  Python  y luego  invocar  len() 
sobre  el  resultado. 

Dependiendo  de  la  base  de  datos  que  estes  utilizando  (e.g.,  PostgreSQL  o MySQL), 
countf)  podria  devolver  un  entero  largo  en  vez  de  un  entero  normal  de  Python.  Esto 
es  una  caracterfstica  particular  de  la  implementation  subyacente  que  no  deberia  ser 
ningun  problema  en  la  vida  real. 

in_bulk(id_list) 


Este  metodo  toma  una  lista  de  claves  primarias  y devuelve  un  diccionario  que  mapea 
cada  clave  primaria  en  una  instancia  con  el  ID  dado,  por  ejemplo: 

»>  Blog. objects. in_bulk([l]) 

{1:  Beatles  Blog} 

»>  Blog. objects. in_bulk([l,  2]) 
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{1:  Beatles  Blog,  2:  Cheddar  Talk} 

>»  Blog. objects. in_bulk([]) 

{} 


Si  no  se  encuentra  un  objeto  en  la  base  para  un  ID  en  particular,  este  id  no 
aparecera  en  el  diccionario  resultante.  Si  le  pasas  una  lista  vacia  a in_biilk(), 
obtendras  un  diccionario  vacio. 

latest(field_name=None) 

Devuelve  el  ultimo  objeto  de  la  tabla,  ordenados  por  fecha,  utilizando  el  campo  que 
se  provea  en  el  argumento  fleld_nombre  como  fecha.  Este  ejemplo  devuelve  el 
Entrada  mas  reciente  en  la  tabla,  de  acuerdo  con  el  campo  fecha_publicacion: 

>»  Entrada. objects. latest(’fecha_publicacion’) 

Si  el  Meta  de  tu  modelo  especifica  get_latest_by,  se  puede  omitir  el  argumento 
field_nombre.  Django  utilizara  el  campo  indicado  en  get_latest_by  por  defecto. 

A1  igual  que  get!),  latest!)  levanta  DoesNotExist  si  no  existe  un  objeto  con  los 
parametros  provistos. 


Patrones  de  busqueda 


Los  patrones  de  busqueda  son  la  manera  en  que  se  especifica  la  carne  de  una 
clausula  WHERE  de  SQL.  Consisten  de  argumentos  de  palabra  clave  para  los  metodos 
filterO,  exclude!)  y get!)  de  QuerySet. 

Los  parametros  basicos  de  busqueda  toman  la  forma  de 
campo tipodebusqueda=valor  !notar  el  doble  guion  bajo).  Por  ejemplo: 

»>  Entrada. objects. filter(fecha_publicacion Ite- 2006-01-01’) 

Se  traduce  aproximadamente  en  el  siguiente  comando  SQL: 

SELECT  * FROM  blog_entrada  WHERE  fecha_publicacion  <=  '2006-01-01'; 

Si  se  suministra  un  argumento  de  palabra  clave  invalido,  la  funcion  levantara  una 
exception  de  TypeError. 

A continuation  se  listan  los  tipos  de  busqueda  que  existen. 

exact 

Realiza  una  busqueda  por  coincidencias  exactas: 

»>  Entrada. objects. get(titulo exact="Los  Beatles") 

Esto  busca  objetos  que  tengan  en  el  campo  titulo  la  frase  exacta  “Man  bites  dog”. 

Si  no  se  suministra  un  tipo  de  busqueda  - O sea,  si  tu  argumento  de  palabra  clave 
no  contiene  un  doble  guion  bajo  - el  tipo  de  busqueda  se  asume  como  exact. 

Por  ejemplo,  las  siguientes  dos  sentencias  son  equivalentes: 

»>  Blog. objects. get(id exact=14)  # De  forma  explicita 

»>  Blog. objects. get(  d=14)  # exact  esta  implicito 
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Esto  es  por  conveniencia,  dado  que  las  busquedas  con  tipo  de  busqueda  exact  son 
las  mas  frecuentes. 

iexact 

Realiza  una  busqueda  por  coincidencias  exactas  sin  distinguir  mayusculas  de 
minusculas: 

»>  Blog. objects. get(nombre iexact- beatles  blog') 

Esta  consulta  traera  objetos  con  nombre  'Beatles  Blog',  'beatles  blog',  'BeAtLes 
BLoG',  etcetera. 

contains 

Realiza  una  busqueda  de  subcadenas,  distinguiendo  mayusculas  y minusculas: 
»>Entrada. objects. get(titulo contains- Lennon’) 


Esto  coincidira  con  el  titular  'Today  Lennon  honored'  pero  no  con  'today  lennon 
honored'. 

SQLite  no  admite  sentencias  LIKE  distinguiendo  mayusculas  y minusculas;  cuando  se 
utiliza  SQLite,  contains  se  comporta  como  icontains. 


ESCAPADO  DE  PORCIENTO  Y GUION  BAJO  EN  SENTENCIAS  LIKE 


Los  patrones  de  busqueda  que  resulten  en  sentencias  SQL  LIKE  (iexact,  contains, 
icontains,  startswith,  istartswith,  endswith,  y iendswith)  escaparan  automaticamente 
los  dos  caracteres  especiales  utilizados  en  sentencias  LIKE  - el  porciento  y el  guion 
bajo.  (En  una  sentencia  LIKE,  el  simbolo  de  porciento  indica  una  secuencia  de 
caracteres  cualesquiera,  y el  guion  bajo  indica  un  solo  caracter  cualquiera). 

Esto  significa  que  las  cosas  deberian  funcionar  de  manera  intuitiva,  porque  la 
abstraction  funciona  bien.  Por  ejemplo,  para  obtener  todos  las  Entradas  que 
contengan  un  simbolo  de  porciento,  simplemente  hace  falta  utilizar  el  simbolo  de 
porcentaje  como  cualquier  otro  caracter: 

Entrada.objects.filter(titulo contains='%') 

Django  se  hace  cargo  del  escapado.  El  SQL  resultante  sera  algo  similar  a esto: 

SELECT  ...  WHERE  titulo  LIKE  '%\%%'; 

Lo  mismo  vale  para  el  guion  bajo.  Tanto  el  simbolo  de  porcentaje  como  el  guion 
bajo  se  deberian  manejar  de  manera  transparente. 


icontains 

Realiza  una  busqueda  de  subcadenas,  sin  distinguir  mayusculas  y minusculas: 
»>  Entrada.objects.get(titulo icontains=’Lennon’) 
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A diferencia  de  contains,  icontains  s/trera  today  lennon  honored. 

gt,  gte,  It,  y lte 

Estos  representan  los  operadores  de  mayor  a,  mayor  o igual  a,  menor  a,  y menor  o 
igual  a,  respectivamente: 

>»  Entrada. objects. filtered gt=4) 

>»  Entrada. objects. filtered lt=15) 

>»  Entrada. objects. filtered gte=l) 

Estas  consultas  devuelven  cualquier  objeto  con  un  ID  mayor  a 4,  un  ID  menor  a 
15,  y un  ID  mayor  o igual  a 1,  respectivamente. 

Por  lo  general  estos  operadores  se  utilizaran  con  campos  numericos.  Se  debe  tener 
cuidado  con  los  campos  de  caracteres,  ya  que  el  orden  no  siempre  es  el  que  uno  se 
esperaria  (i.e.,  la  cadena  “4”  resulta  ser  mayor  que  la  cadena  “10”). 

in 

Aplica  un  filtro  para  encontrar  valores  en  una  lista  dada: 

Entrada. objects. filtered in=[l,  3,  4]) 

Esto  devolvera  todos  los  objetos  que  tengan  un  ID  de  1,  3 o 4. 

startswith 

Busca  coincidencias  de  prefijos  distinguiendo  mayusculas  y minusculas: 

»>  Entrada. objects. filter(titulo startswith- Will’) 

Esto  encontrara  los  titulares  “Will  he  run?”  y “Willbur  nombred  judge”,  pero  no 
“Who  is  Will?”  o “will  found  in  crypt”. 


istartswith 

Realiza  una  busqueda  por  prefijos,  sin  distinguir  mayusculas  y minusculas: 

»>  Entrada. objects. filter(titulo istartswith- will') 

Esto  devolvera  los  titulares  “Will  he  run?”,  “Willbur  nombred  judge”,  y “will  found 
in  crypt”,  pero  no  “Who  is  Will?” 

endswith  y iendswith 

Realiza  busqueda  de  sufijos,  distinguiendo  y sin  distinguir  mayusculas  de 
minusculas,  respectivamente: 

»>  Entrada. objects. filter(titulo endswith- cats’) 

»>  Entrada. objects. filter(titulo iendswith-cats) 
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range 

Realiza  una  busqueda  por  rango: 

»>  start_date  = datetime. date(2005,  1,  1) 

»>  end_date  = datetime. date(2005,  3,  31) 

»>  Entrada. objects. filter(fecha_publicacion range=(start_date,  end_date)) 

Se  puede  utilizar  range  en  cualquier  lugar  donde  podrfas  utilizar  BETWEEN  en 
SQL  - para  fechas,  numeros,  e incluso  cadenas  de  caracteres. 

year,  month,  and  day 

Para  campos  date  y datetime,  realiza  busqueda  exacta  por  ano,  mes  o dia: 

# Busqueda  por  ano 

»>Entrada. objects. filter(fecha_publicacion year=2005) 

# Busqueda  por  mes  - toma  enteros 

»>  Entrada. objects. filter(fecha_publicacion month=12) 

# Busqueda  por  dia 

»>  Entrada. objects. filter(fecha_publicacion day=3) 

# Combinacion:  devuelve  todas  las  entradas  de  Navidad  de  cualquier  ano 

»>  Entrada. objects. filter(fecha_publicacion month=12,  fecha_publicacion day=25) 

isnull 

Toma  valores  True  o False,  que  corresponderan  a consultas  SQL  de  IS  NULL"y  "IS 
NOT  NULL,  respectivamente: 

»>  Entrada. objects. filter(fecha_publicacion isnull=T rue) 


isnull=True  vs. exact=None 


Hay  una  diferencia  importante  entre isnull=True  y exact=None. exact=None 

siempre  devolvera  como  resultado  un  conjunto  vacio,  ya  que  SQL  requiere  que 

ningun  valor  sea  igual  a NULL. isnull  determina  si  el  campo  actualmente  contiene 

un  valor  NULL  sin  realizar  la  comparacion. 

search 

Un  booleano  que  realiza  busquedas  full-text,  que  aprovecha  el  indexado  full-text. 
Esto  es  como  contains  pero  significativamente  mas  rapido  debido  al  indexado  full- 
text. 

Notese  que  este  tipo  de  busqueda  solo  esta  disponible  en  MySQL  y requiere  de 
manipulation  directa  de  la  base  de  datos  para  agregar  el  indice  full-text. 
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El  patron  de  busqueda  pk 

Por  conveniencia,  Django  provee  un  patron  de  busqueda  pk,  que  realiza  una 
busqueda  sobre  la  clave  primaria  del  modelo  (pk  por  primary  key,  del  ingles). 

En  el  modelo  de  ejemplo  Blog,  la  clave  primaria  es  el  campo  id,  asi  que  estas 
sentencias  sedan  equivalentes: 

»>  Blog. objects. get(id exact=14)  # Forma  explicita 

»>  Blog. objects. get(id=14)  # exact  implicito 

»>  Blog. objects. get(pk=  14)  # pk  implica  id exact 

El  uso  de  pk  no  se  limita  a busquedas exact,  cualquier  patron  de  busqueda 

puede  ser  combinado  con  pk  para  realizar  una  busqueda  sobre  la  clave  primaria  de 
un  modelo: 

# Buscar  entradas  en  blogs  con  id  1,  4,  o 7 

»>  Blog. objects. filter(pk in=[l,4,7]) 

# Buscar  entradas  en  blogs  con  id  > 14 

»>  Blog. objects. filter(pk gt=14) 

Las  busquedas  por  pk  tambien  funcionan  con  joins.  Por  ejemplo,  estas  tres 
sentencias  son  equivalentes: 

»>  Entrada.objects.filter(blog id exact=3)  # Forma  explicita 

»>  Entrada.objects.filter(blog id=3)  # exact  implicito 

»>  Entrada.objects.filter(blog pk=3)  # pk  implica id exact 


Busquedas  complejas  con  Objetos  Q 


Los  argumentos  de  palabras  clave  en  las  busquedas  - en  filter()  por  ejemplo  - son 
unidos  con  AND.  Si  necesitas  realizar  busquedas  mas  complejas  (e.g.,  busquedas  con 
sentencias  OR),  puedes  utilizar  objetos  Q. 

Un  objeto  Q (django.db.models.Q)  es  un  objeto  que  se  utiliza  para  encapsular  una 
coleccion  de  argumentos  de  palabra  clave.  Estos  argumentos  de  palabra  clave  son 
especificados  como  se  indica  en  la  seccion  “Patrones  de  busqueda”. 

Por  ejemplo,  este  objeto  Q encapsula  una  consulta  con  un  unico  LIKE: 

Q(question startswith- What’) 

Los  objetos  Q pueden  ser  combinados  utilizando  los  operadores  & y |.  Cuando  se 
utiliza  un  operador  sobre  dos  objetos,  se  obtiene  un  nuevo  objeto  Q.  Por  ejemplo,  un 
OR  de  dos  consultas  question startswith  seria: 

Q(question startswith- Who')  | Q(question startswith- What’) 

Esto  sera  equivalente  a la  siguiente  clausula  WE1ERE  en  SQL: 

WHERE  question  LIKE  Who%’  OR  question  LIKE  What%’ 

Puede  componer  sentencias  de  complejidad  arbitraria  combinando  objetos  Q con 
los  operadores  & y |.  Tambien  se  pueden  utilizar  parentesis  para  agrupar. 
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Cualquier  funcion  de  busqueda  que  tome  argumentos  de  palabra  clave  (e.g., 
fillerO,  excludeO,  get())  puede  recibir  tambien  uno  o mas  objetos  Q como  argumento 
posicional  (no  nombrado).  Si  se  proveen  multiples  objetos  Q como  argumentos  a una 
funcion  de  busqueda,  los  argumentos  seran  unidos  con  AND,  por  ejemplo: 

Poll. objects. get( 

Q(question startswith- Who), 

Q(fecha_publicacion=date(2005,  5,  2))  | Q(fecha_publicacion=date(2005,  5,  6)) 

) 


Se  traduce  aproximadamente  en  la  siguiente  sentencia  SQL: 

SELECT  * from  polls  WHERE  question  LIKE  Who%' 

AND  (fecha_publicacion  = '2005-05-02'  OR  fecha_publicacion  = '2005-05-06') 

Las  funciones  de  busqueda  pueden  ademas  mezclar  el  uso  de  objetos  Q y de 
argumentos  de  palabra  clave.  Todos  los  argumentos  provistos  a una  funcion  de 
busqueda  (sean  argumentos  de  palabra  clave  u objetos  Q)  son  unidos  con  AND.  Sin 
embargo,  si  se  provee  un  objeto  Q debe  preceder  la  definition  de  todos  los 
argumentos  de  palabra  clave.  Por  ejemplo,  lo  siguiente: 

Poll. objects. get( 

Q(fecha_publicacion=date(2005,  5,  2))  | Q(fecha_publicacion=date(2005,  5,  6)), 
question startswith- Who’) 

Es  una  consulta  valida,  equivalente  al  ejemplo  anterior,  pero  esto: 

# CONSULTA  IN  VALIDA 

Poll. objects. get( 

question startswith- Who’, 

Q(fecha_publicacion=date(2005,  5,  2))  | Q(fecha_publicacion=date(2005,  5,  6) ) ) 

No  es  valido. 

Hay  algunos  ejemplos  disponibles  online  en 

http://www.djangoproject.com/documentation/ . 


Objetos  Relacionados 


Cuando  defines  una  relacion  en  un  modelo  (i.e.  un  ForeignKey,  OneToOneField,  or 
ManyToManyField),  las  instancias  de  ese  modelo  tendran  una  API  conveniente  para 
acceder  a estos  objetos  relacionados. 

Por  ejemplo,  si  e es  un  objeto  Entrada,  puede  acceder  a su  Blog  asociado 
accediendo  al  atributo  blog,  esto  es  e.blog. 

Django  tambien  crea  una  API  para  acceder  al  “otro”  lado  de  la  relacion  - el 
vinculo  del  modelo  relacionado  al  modelo  que  define  la  relacion.  Por  ejemplo,  si  b es 
un  objeto  Blog,  tiene  acceso  a la  lista  de  todos  los  objetos  Entrada  a traves  del 
atributo  entrada_set:  b.entrada_set.all(). 

Todos  los  ejemplos  en  esta  seccion  utilizan  los  modelos  de  ejemplo  Blog,  Autor  y 
Entrada  que  se  definen  al  principio  de  esta  seccion. 
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Consultas  Que  Cruzan  Relaciones 

Django  ofrece  un  mecanismo  poderoso  e intuitivo  para  “seguir”  relaciones  cuando  se 
realizan  busquedas,  haciendose  cargo  de  los  JOINs  de  SQL  de  manera  automatica. 
Para  cruzar  una  relacion  simplemente  hace  falta  utilizar  el  nombre  de  campo  de  los 
campos  relacionados  entre  modelos,  separados  por  dos  guiones  bajos,  hasta  que 
llegues  al  campo  que  necesitabas. 

Este  ejemplo  busca  todos  los  objetos  Entrada  que  tengan  un  Blog  cuyo  nombre 
sea  'Beaties  Blog': 

»>  Entrada. objects. filter(blog nombre exact- Beatles  Blog') 

Este  camino  puede  ser  tan  largo  como  quieras. 

Tambien  Funciona  en  la  otra  direction.  Para  referirse  a una  relacion  “inversa”, 
simplemente  hay  que  utilizar  el  nombre  en  minusculas  del  modelo. 

Este  ejemplo  busca  todos  los  objetos  Blog  que  tengan  al  menos  un  Entrada  cuyo 
titulo  contenga  'Lennon': 

»>  Blog. objects. filter(entrada titulo contains- Lennon') 


Relaciones  de  Clave  Foranea 

Si  un  modelo  contiene  un  ForeignKey,  las  instancias  de  ese  modelo  tendran  acceso  al 
objeto  relacionado  (foraneo)  a traves  de  un  simple  atributo  del  modelo,  por  ejemplo: 

e = Entrada.objects.get(id=2) 

e.blog  # Devuelve  el  objeto  Blog  relacionado 

Se  puede  acceder  y asignar  el  valor  de  la  clave  foranea  via  el  atributo.  Como  seria 
de  esperar,  los  cambios  a la  clave  foranea  no  se  guardan  en  el  modelo  hasta  que 
invoques  el  metodo  save(),  por  ejemplo: 

e = Entrada.objects.get(id=2) 
e.blog  = some_blog 
e.save() 

Si  un  campo  ForeignKey  tiene  la  option  null=True  seteada  (i.e.  permite  valores 
NULL),  se  le  puede  asignar  None: 

e = Entrada.objects.get(id=2) 
e.blog  = \lone 

e.save()  # "UPDATE  blog_entrada  SET  blogjd  = NULL  ...;" 

El  acceso  a relaciones  uno-a-muchos  se  almacena  la  primera  vez  que  se  accede  al 
objeto  relacionado.  Cualquier  acceso  subsiguiente  a la  clave  foranea  del  mismo 
objeto  son  cacheadas,  por  ejemplo: 

e = Entrada.objects.get(id=2) 

print  (e.blog  )#  Busca  el  Blog  asociado  en  la  base  de  datos. 
print  (e.blog)  # No  va  a la  base  de  datos;  usa  la  version  cacheada. 

Notar  que  el  metodo  de  QuerySet  select_related()  busca  inmediatamente  todos  los 
objetos  de  relaciones  uno-a-muchos  de  la  instancia: 
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e = Entrada.objects.select_related().get(id=2) 

print  (e.blog)  # No  va  a la  base  de  datos;  usa  la  version  cacheada. 

print  (e.blog)  # No  va  a la  base  de  datos;  usa  la  version  cacheada. 

select_related()  esta  documentada  en  la  section  “Metodos  de  consulta  que 
retornan  nuevos  QuerySets”. 


Relaciones  de  Clave  Foreanea  “Inversas” 

Las  relaciones  de  clave  foranea  son  automaticamente  simetricas  - se  infiere  una 
relation  inversa  de  la  presencia  de  un  campo  ForeignKey  que  apunte  a otro  modelo. 

Si  un  modelo  tiene  una  ForeignKey,  las  instancias  del  modelo  de  la  clave  foranea 
tendran  acceso  a un  Manager  que  devuelve  todas  las  instancias  del  primer  modelo. 
Por  defecto,  este  Manager  se  llama  FOO_set,  donde  FOO  es  el  nombre  modelo  que 
contiene  la  clave  foranea,  todo  en  minusculas.  Este  Manager  devuelve  QuerySets,  que 
pueden  ser  filtradas  y manipuladas  como  se  describe  en  la  section  “Recuperando 
objetos”. 

Aqui  se  muestra  un  ejemplo: 
b = Blog.objects.get(id=l) 

b.entrada_set.all()  # Encontrar  todos  los  objetos  Entrada  relacionados  a b. 

# b.entrada_set  es  un  Manager  que  devuelve  QuerySets. 

b.entrada_set.filter(titulo contains- Lennon’) 

b.entrada_set.count() 

Se  puede  cambiar  el  nombre  del  atributo  FOO_set  indicando  el  parametro 
related_name  en  la  definition  del  ForeignKeyQ.  Por  ejemplo,  si  el  modelo  Entrada 
fuera  cambiado  por  blog  = ForeignKey(Blog,  related_name='entradas'),  el  ejemplo 
anterior  pasaria  a ser  asi: 

b = Blog,  objects.  get(id=l) 

b.entradas.allQ  # Encontrar  todos  los  objetos  Entrada  relacionados  a b. 

# b. entries  es  un  Manager  que  devuelve  QuerySets. 

b.entradas.filter(titulo contains- Lennon’) 

b.entradas.count() 

No  se  puede  acceder  al  Manager  de  ForeignKey  inverso  desde  la  clase  misma;  debe 
ser  accedido  desde  una  instancia: 

Blog.entrada_set  # Raises  AttributeError:  "Manager  must  be  accessed  via  instance". 

Ademas  de  los  metodos  de  QuerySet  definidos  en  la  section  “Recuperando 
Objetos”,  el  Manager  de  ForeignKey  tiene  los  siguientes  metodos  adicionales: 

• add(objl,  obj2,  ...):  Agrega  los  objetos  del  modelo  indicado  al  conjunto  de 
objetos  relacionados,  por  ejemplo: 

b = Blog,  objects.  get(id=l) 
e = Entrada.  objects.  get(id=234) 

b.entrada_set.add(e)  # Associates  Entrada  e with  Blog  b. 

• create (• **kwargs):  Crea  un  nuevo  objeto,  lo  guarda,  y lo  deja  en  el  conjunto  de 

objetos  relacionados.  Devuelve  el  objeto  recien  creado: 
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b = Blog,  objects.  get(  =1) 
e = b.entrada_set.create(titulo- Hello’,  texto=’Hi’, 
fecha_publicacion=datetime.date(2005, 1,  1)) 

# No  hace  falta  llamar  a e.save()  aca  --  ya  ha  sido  guardado 

Esto  es  equivalente  a (pero  mas  simple  que)  lo  siguiente: 

»>b  = Blog,  objects.  get(id=l) 

»>e  = Entrada(blog=b,  titulo='Hello',  texto='Hi', 

fecha_publicacion=datetime.date(2005,  1,  1)) 

»>  e.save() 

Nota  que  no  es  necesario  especificar  el  argumento  de  palabra  clave 
correspondiente  al  modelo  que  define  la  relacion.  En  el  ejemplo  anterior,  no 
le  pasamos  el  parametro  blog'  a create!).  Django  deduce  que  el  campo 
Entrada  del  nuevo  blog  deberiaserb. 

• remove(objl,  obj2,  ...):  Quita  los  objetos  indicados  del  conjunto  de  objetos 
relacionados: 

b = Blog,  objects.  get(id=l) 
e = Entrada. objects. get(id=234) 

b.entrada_set.remove(e)  # Desasocia  la  Entrada  e del  Blog  b. 

Para  evitar  inconsistencias  en  la  base  de  datos,  este  metodo  solo  existe  para 
objetos  ForeignKey  donde  null=True.  Si  el  campo  relacionado  no  puede  pasar 
ser  None  (NULL),  entonces  un  objeto  no  puede  ser  quitado  de  una  relacion 
sin  ser  agregado  a otra.  En  el  ejemplo  anterior,  al  quitar  a ede  b.entrada_set() 
es  equivalente  a hacer  e.blog  = None,  y dado  que  la  definition  del  campo 
ForeignKey  blog  (en  el  modelo  Entrada)  no  indica  null=True,  esto  es  una 
action  invalida. 

• clear () : Quita  todos  los  objetos  del  conjunto  de  objetos  relacionados: 

b = Blog,  objects.  get(id=l) 
b.entrada_set.clear() 


Nota:  que  esto  no  borra  los  objetos  relacionados  — simplemente  los 
desasocia. 


Al  igual  que  removeO,  clear  solo  esta  disponible  para  campos 
ForeignKey  donde  null=True. 

Para  asignar  todos  los  miembros  de  un  conjunto  relacionado  en  un  solo  paso, 
simplemente  se  le  asigna  al  conjunto  un  objeto  iterable,  por  ejemplo: 

b = Blog,  objects.  get(id=l) 
b.entrada_set  = [el,  e2] 
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Si  el  metodo  clear()  esta  definido,  todos  los  objetos  pre-existentes  seran 
quitados  del  entrada_set  antes  de  que  todos  los  objetos  en  el  iterable  (en  este 
caso,  la  lista)  sean  agregados  al  conjunto.  Si  el  metodo  clear()  no  esta 
disponible,  todos  los  objetos  del  iterable  son  agregados  al  conjunto  sin  quitar 
antes  los  objetos  pre-existentes. 

Todas  las  operaciones  “inversas”  definidas  en  esta  seccion  tienen  efectos 
inmediatos  en  la  base  de  datos.  Toda  creation,  borradura  y agregado  son 
inmediata  y automaticamente  grabados  en  la  base  de  datos. 


Relaciones  muchos-a-muchos 

Ambos  extremos  de  las  relaciones  muchos-a-muchos  obtienen  una  API  de  acceso 
automaticamente.  La  API  funciona  igual  que  las  funciones  “inversas”  de  las 
relaciones  uno-a-muchos  (descriptas  en  la  seccion  anterior). 

La  unica  diferencia  es  el  nombrado  de  los  atributos:  el  modelo  que  define  el 
campo  ManyToManyField  usa  el  nombre  del  atributo  del  campo  mismo,  mientras 
que  el  modelo  “inverso”  utiliza  el  nombre  del  modelo  original,  en  minusculas,  con  el 
sufijo  '_set'  (tal  como  lo  hacen  las  relaciones  uno-a-muchos). 

Un  ejemplo  de  lo  anterior  lo  hara  mas  facil  de  entender: 

e = Entrada.objects.get(id=3) 

e.autores.allO  # Devuelve  todos  los  objetos  Autor  para  este  Entrada. 
e.autores.count() 

e.autores.filter(nombre contains- John’) 

a = Autor.  objects.  get(id=5) 

a.entrada_set.all()  # Devuelve  todos  los  obejtos  Entrada  para  este  Autor. 

Al  igual  que  los  campos  ForeignKey,  los  ManyToManyField  pueden  indicar  un 
related_name.  En  el  ejemplo  anterior,  si  el  campo  ManyToManyField  en  el  modelo 
Entrada  indicara  related_name=' entries',  cualquier  instancia  de  Autor  tendria  un 
atributo  entries  en  vez  de  entrada_set. 


Como  son  posibles  las  relaciones  inversas? 


El  mapeador  objeto-relacional  requiere  que  definas  relaciones  en  ambos  extremos. 
Los  desarrolladores  Django  creen  que  esto  es  una  violation  del  principio  DRY  (Don’t 
Repeat  Yourself),  asi  que  Django  solo  te  exige  que  definas  la  relation  en  uno  de  los 
extremos.  ^Pero  como  es  esto  posible,  dado  que  una  clase  modelo  no  sabe  que  otros 
modelos  se  relacionan  con  el  hasta  que  los  otros  modelos  sean  cargados? 

La  respuesta  yace  en  la  variable  INSTALLED_APPS.  La  primera  vez  que  se  carga 
cualquier  modelo,  Django  itera  sobre  todos  los  modelos  en  INSTALLED_APPS  y crea 
las  relaciones  inversas  en  memoria  como  sea  necesario.  Esencialmente,  una  de  las 
funciones  de  INSTALLES_APPS  es  indicarle  a Django  el  dominio  completo  de 
modelos  que  se  utiliza. 


Consultas  que  Abarcan  Objetos  Relacionados 


Las  consultas  que  involucran  objetos  relacionados  siguen  las  mismas  reglas  que  las 
consultas  que  involucran  campos  normales.  Cuando  se  indica  el  valor  que  se  requiere 
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en  una  busqueda,  se  puede  utilizar  tanto  una  instancia  del  modelo  o bien  el  valor  de 
la  clave  primaria  del  objeto. 

Por  ejemplo,  si  b es  un  objeto  Blog  con  id=5,  las  tres  siguientes  consultas  son 
identicas: 

Entrada.objects.filter(blog=b)  # Consulta  usando  un  objeto  de  una  instancia. 
Entrada.objects.filter(blog=b.id)  # Consulta  usando  el  id  de  una  instancia. 
Entrada.objectsdilter(blog=r)  # Consulta  usando  un  id  directamente 


Borrando  Objetos 


El  metodos  para  borrar  se  llama  delete ()•  Este  metodo  inmediatamente  borra  el 
objeto  y no  tiene  ningun  valor  de  retorno: 

e.delete() 

Tambien  se  puede  borrar  objetos  en  grupo.  Todo  objeto  QuerySet  tiene  un  metodo 
deleteO  que  borra  todos  los  miembros  de  ese  QuerySet.  Por  ejemplo,  esto  borra  todos 
los  objetos  Entrada  que  tengan  un  ano  de  fecha_publicacion  igual  a 2005: 

Entrada. objects. filter(fecha_publicacion year=2005).delete() 


Cuando  Django  borra  un  objeto,  emula  el  comportamiento  de  la  restriction  de 
SQL  ON  DELETE  CASCADE  - en  otras  palabras,  todos  los  objetos  que  tengan  una 
clave  foranea  que  apunte  al  objeto  que  esta  siendo  borrado  seran  borrados  tambien, 
por  ejemplo: 

b = Blog,  objects.  get(pk=l) 

# Esto  borra  el  Blog  y todos  sus  objetos  Entrada. 

b. delete() 

Nota  que  deleteO  es  el  unico  metodo  de  QuerySet  que  no  esta  expuesto  en  el 
Manager  mismo.  Esto  es  un  mecanismo  de  seguridad  para  evitar  que 
accidentalmente  solicites  Entrada.objects. deleteO  y borres  todos  los  Entrada.  Si 
realmente  quieres  borrar  todos  los  objetos,  hay  que  pedirlo  explicitamente  al 
conjunto  completo  de  objetos: 

Entrada. objects. allQ.deleteQ 


Metodos  de  Instancia  Adicionales 


Ademas  de  saveO  y deleteO,  un  objeto  modelo  puede  tener  cualquiera  o todos  de  los 
siguientes  metodos. 
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get_FOO_display() 

Por  cada  campo  que  indica  la  option  choices,  el  objeto  tendra  un  metodo 
get_FOO_display(),  donde  FOO  es  el  nombre  del  campo.  Este  metodo  devuelve  el 
valor  “legible”  del  campo.  Por  ejemplo,  en  el  siguiente  modelo: 

GENDER_CHOICES  = ( 

('M’,  ’Masaculino’), 

( F’,  ’Femenino’), 

) 

class  Persona(models. Model): 

nombre  = models.  CharField(max_length=20) 

genero  = models. CharField(max_length=l,  choices=GENDER_CFIOICES) 

Cada  instancia  de  Persona  tendra  un  metodo  get_genero_display: 

»>  p = Persona(nombre=’John’,  genero=’M’) 

»>  p.save() 

»>  p. genero 

’M’ 

»>  p.get_genero_display() 

’Masculino’ 


get_next_by_FOO(**kwargs)  y get_previous_by_FOO(**kwargs) 

Por  cada  campo  DateField  y DateTimeField  que  no  tenga  null=True,  el  objeto  tendra 
dos  metodos  get_next_by_FOO()  y get_previous_by_FOO(),  donde  FOO  es  el  nombre 
del  campo.  Estos  metodos  devuelven  el  objeto  siguiente  y anterior  en  orden 
cronologico  respecto  del  campo  en  cuestion,  respectivamente,  levantando  la 
exception  DoesNotExist  cuando  no  exista  tal  objeto. 

Ambos  metodos  aceptan  argumentos  de  palabra  clave  opcionales,  que  deberian 
ser  de  la  forma  descripta  en  la  section  “Patrones  de  busqueda”. 

Notar  que  en  el  caso  de  valores  de  fecha  identicos,  estos  metodos  utilizaran  el  ID 
como  un  chequeo  secundario.  Esto  garantiza  que  no  se  saltearan  registros  ni 
apareceran  duplicados.  Hay  un  ejemplo  completo  en  los  ejemplos  de  la  API  de 
busqueda,  en  http://www.djangoproject.com/documentation. 

get_FOO_filename  () 

Todo  campo  FileField  le  dara  al  objeto  un  metodo  get_FOO_filename(),  donde  FOO 
es  el  nombre  del  campo.  Esto  devuelve  el  nombre  de  archivo  completo  en  el  sistema 
de  archivos,  de  acuerdo  con  la  variable  MEDIA_ROOT. 

Nota  que  el  campo  ImageField  es  tecnicamente  una  subclase  de  FileField,  asi  que 
todo  modelo  que  tenga  un  campo  ImageField  obtendra  tambien  este  metodo. 

get_FOO_url() 

Por  todo  campo  FileField  el  objeto  tendra  un  metodo  get_FOO_url(),  donde  FOO  es  el 
nombre  del  campo.  Este  metodo  devuelve  la  URL  al  archivo,  de  acuerdo  con  tu 
variable  MEDIA_URL. 

Si  esta  variable  esta  vacia,  el  metodo  devolvera  una  cadena  vacia. 
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get_FOO_size() 

Por  cada  campo  FileField  el  objeto  tendra  un  metodo  get_FOO_size(),  donde  FOO  es 
el  nombre  del  campo.  Este  metodo  devuelve  el  tamano  del  archivo,  en  bytes.  (La 
implementation  de  este  metodo  utiliza  os.path.getsize.) 

save_FOO_file  (filename,  raw_contents) 

Por  cada  campo  FileField,  el  objeto  tendra  un  metodo  save_FOO_file(),  donde  FOO  es 
el  nombre  del  campo.  Este  metodo  guarda  el  archivo  en  el  sistema  de  archivos, 
utilizando  el  nombre  dado.  Si  un  archivo  con  el  nombre  dado  ya  existe,  Django  le 
agrega  guiones  bajos  al  final  del  nombre  de  archivo  (pero  antes  de  la  extension)  hasta 
que  el  nombre  de  archivos  este  disponible. 

get_FOO_height()  and  get_FOO_width() 

Por  cada  campo  ImageField,  el  objeto  obtendra  dos  metodos,  get_FOO_height()  y 
get_FOO_width(),  donde  FOO  es  el  nombre  del  campo.  Estos  metodos  devuelven  el 
alto  y el  ancho  (respectivamente)  de  la  imagen,  en  pixeles,  como  un  entero. 


Atajos  (Shortcuts) 


A medida  que  desarrolles  tus  vistas,  descubriras  una  serie  de  modismos  en  la  manera 
de  utilizar  la  API  de  la  base  de  datos.  Django  codifica  algunos  de  estos  modismos 
como  atajos  que  pueden  ser  utilizados  para  simplificar  el  proceso  de  escribir  vistas. 
Estas  funciones  se  pueden  hallar  en  el  modulo  django. shortcuts. 

get_ob  j ect_or_404 () 

Un  modismo  frecuente  es  llamar  a get()  y levantar  un  Flttp404  si  el  objeto  no  existe. 
Este  modismo  es  capturado  en  la  funcion  get_object_or_404().  Esta  funcion  toma  un 
modelo  Django  como  su  primer  argumento,  y una  cantidad  arbitraria  de  argumentos 
de  palabra  clave,  que  le  pasa  al  metodo  get()  del  Manager  por  defecto  del  modelo. 
Luego  levanta  un  Flttp404  si  el  objeto  no  existe,  por  ejemplo: 

# Obtiene  una  Entrada  con  una  clave  primaria  3 

e = get_object_or_404(Entrada,  pk=3) 

Cuando  se  le  pasa  un  modelo  a esta  funcion,  se  utiliza  el  Manager  por  defecto  para 
ejecutar  la  consulta  get()  subyacente.  Si  no  quieres  que  se  utilice  el  manager  por 
defecto,  o si  quiere  buscar  en  una  lista  de  objetos  relacionados,  se  le  puede  pasar  a 
get_object_or_404()  un  objeto  Manager  en  vez: 

# Obtiene  el  autor  del  blog  con  una  intancia  de  e,  con  el  nombre  de  ’Fred’ 

a = get_object_or_404(e.autores,  nombre- Fred’) 

# Usa  un  manager  personalizado  ’entradas_recientes’  en  la  busqueda  de  una  entrada 

# con  una  clave  primaria  3 

e = get_object_or_404(Entrada.  entradas_recientes,  pk=3) 
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get_list_or_404 () 

get_list_or_404()  se  comporta  igual  que  ge  t_o b jec t_o  r_4 04  () , salvo  porque  llama  a 
filter()  en  vez  de  a get  ()  • Levanta  un  Http404  si  la  lista  resulta  vacia. 


Utilizando  SQL  Crudo 


Si  te  encuentras  necesitando  escribir  una  consul ta  SQL  que  es  demasiado  compleja 
para  manejarlo  con  el  mapeador  de  base  de  datos  de  Django,  todavia  puede  optar  por 
escribir  la  sentencia  directamente  en  SQL  crudo. 

La  forma  preferida  para  hacer  esto  es  dandole  a tu  modelo  metodos  personalizados 
o metodos  de  Manager  personalizados  que  realicen  las  consultas.  Aunque  no  exista 
ningun  requisito  en  Django  que  exija  que  las  consultas  a la  base  de  datos  vivan  en  la 
capa  del  modelo,  esta  implementation  pone  a toda  tu  logica  de  acceso  a los  datos  en 
un  mismo  lugar,  lo  cual  es  una  idea  astuta  desde  el  punto  de  vista  de  organization  del 
codigo. 

Finalmente,  es  importante  notar  que  la  capa  de  base  de  datos  de  Django  es 
meramente  una  interfaz  a tu  base  de  datos.  Puedes  acceder  a la  base  de  datos 
utilizando  otras  herramientas,  lenguajes  de  programacion  o frameworks  de  bases  de 
datos  - No  hay  nada  especificamente  de  Django  acerca  de  tu  base  de  datos. 


APENDICE  C 


Referenda  de  las  vistas 
genericas 


El  capitulo  11  es  una  introduction  a las  vistas  gendricas  basadas  en  clases,  pero 

pasa  por  alto  algunos  detalles  importantes.  Este  apendice  describe  todas  las  vistas 
genericas,  junto  con  las  opciones  que  cada  una  de  ellas  puede  aceptar.  Antes  de 
intentar  entender  este  material  de  referencia  es  muy  conveniente  leer  el  capitulo  11. 
Tampoco  viene  mal  un  repaso  a los  modelos  Libro,  Editor  y Autor  definidos  en  dicho 
capitulo,  ya  que  seran  usados  en  los  ejemplos  incluidos  en  este  apendice. 

Argumentos  comunes  a las  vistas  genericas 

basadas  en  clases 

La  mayorfa  de  las  vistas  genericas  basadas  en  clases,  aceptan  algunos  argumentos 
que  pueden  modiflcar  su  comportamiento.  Muchos  de  esos  argumentos  funcionan 
igual  para  la  mayoria  de  las  vistas  (hay  sus  excepciones).  La  tabla  C-l  describe 
algunos  de  estos  argumentos  comunes;  cada  vez  que  veas  uno  de  estos  argumentos 
en  la  lista  de  parametros  admitidos  por  una  vista  generica,  su  comportamiento  sera 
tal  y como  se  describe  en  esta  tabla. 


Argumento 


Descripcion 


allow_empty  Un  valor  booleano  que  indica  como  debe  comportarse  la 

vista  si  no  hay  objetos  disponibles.  Si  vale  False  y no  hay 
objetos,  la  vista  elevara  un  error  404  en  vez  de  mostrar  una 
pagina  vacia.  Su  valor  por  defecto  es  Falsa. 


context_object_name  El  nombre  de  la  variable  principal  en  el  contexto  de  la 

plantilla.  Por  defecto,  es  'object'.  Para  las  listas  que  utilizan 
mas  de  objeto  (por  ejemplo,  las  vistas  de  listados  o de 
archivos  por  fechas),  se  anade  el  sufijo  '_list'  al  valor  de  este 
parametro,  asi  que  si  no  se  indica  nada  y la  vista  utiliza  varios 
objetos,  estos  estaran  accesibles  mediante  una  variable 
llamada  objectlist. 


context_processors  Es  una  lista  de  procesadores  de  contexto  adicionales  (ademas 

de  los  incluidos  por  el  sistema),  que  se  aplican  a la  plantilla 
de  la  vista. 


model 


El  modelo  del  cual  la  vista  mostrara  los  datos.  Especificar 
model  = Foo  es  tan  efectivo  como  especificar  queryset  = 
Foo. objects. all() 
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mimetype 


queryset 


paginatejby 


template_name 


El  tipo  MIME  a usar  para  el  documento  resultante.  Por 
defecto  utiliza  el  tipo  definido  en  la  variable  de  configuration 
DEFAULT_MIME_TYPE,  cuyo  valor  inicial  es  text/html. 

Un  objeto  de  tipo  QuerySet  (por  ejemplo,  Autor.objects.allO) 
del  cual  se  leeran  los  objetos  a utilizar  por  la  vista.  En  el 
apendice  C hay  mas  information  acerca  de  los  objetos 
QuerySet.  La  mayoria  de  las  vistas  genericas  necesitan  este 
argumento. 

El  numero  maximo  de  objetos  para  paginar  permitidos  en 
una  plantilla  (Disponible  solo  en  listas  de  objetos). 

El  nombre  completo  de  la  plantilla  a usar  para  representar  la 
pagina.  Este  argumento  se  puede  usar  si  queremos  modificar 
el  nombre  que  se  genera  automaticamente  a partir  del 
QuerySet. 


Tabla  C- 1.  Argumentos  comunes  a la  mayoria  de  vistas  genericas. 


Vistas  genericas  basadas  en  clases-base 


Dentro  del  modulo  django. views. generic  existen  varias  vistas  sencillas  que  manejan 
unos  cuantos  problemas  frecuentes:  mostrar  una  plantilla  que  no  necesita  una  vista 
logica  TemplateView,  hacer  una  redirection  de  una  pagina  RedirectViewy  la  mas 
importante  de  todas,  la  clase  base  maestra,  de  la  cual  todas  las  demas  clases 
genericas  heredan  llamada  View.  Estas  tres  clases  implementan  muchas  de  las 
funcionalidades  necesitadas  para  crear  vistas  en  Django,  puedes  pensar  en  ellas 
como  'vistas  padres  que  pueden  usarse  en  si  mismas  o heredando  sus  atributos 
dependiendo  de  la  complejidad  y las  necesidades  de  tu  proyecto. 

Muchas  de  las  caracteristicas  incorporadas  en  las  vistas  basadas  en  clases,  heredan 
de  otras  clases  o de  varias  clases  usando  mixins.  Debido  a que  la  cadena  de  herencia 
es  muy  importante,  las  clases  ancestro  estan  documentadas  debajo  del  titulo  de  cada 
section  de  sus  ancestros  (MRO).  MRO  es  un  acronimo  para  el  orden  de  resolution  de 
un  metodo. 


Vista  base:  View 

Clase:  django.views.generic.base.View 

La  clase-base  maestra  de  todas  las  vistas  genericas.  Todas  las  vistas  basadas  en  clases 
genericas  heredan  de  esta  clase  base. 

Flujo  de  metodos: 


1.  dispatch  () 

2.  http_method_not_allowed() 

3.  options  () 
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Ejemplo: 

Para  crear  el  famoso  hola  mundo  usando  una  clase  generica,  creamos  una  vista  View 
importandola  del  modulo  django.  views. generic de  la  siguiente  forma: 


views . py 


from  django. http  import  HttpResponse 
from  django. views. generic  import  View 

class  MiVista(View): 

def  get(self,  request,  *args,  **kwargs): 
return  HttpResponse('iHola,  Mundo!') 


Luego  la  enlazamos  directamente  en  la  URL: 


urls .py 


from  django. conf.urls  import  url 
from  aplicacion. views  import  MiVista 

urlpatterns  = [ 

url(r'Ahola/$',  Mi  Vista.  as_view(),  name- mi-vista'), 

] 

Atributos 

http_method_names;  La  lista  de  nombre  de  metodos  HTTP,  que  esa  vista  acepta 
son: 

Default: 

['get',  'post',  'put',  'patch',  'delete',  'head',  'options',  'trace'] 


Metodos 

• classmethod  as_view(**initkwargs):  Retorna  una  vista  llamable  que  toma 
una  petition  y retorna  una  respuesta: 

response  = MiVista.as_view()(request) 

• dispatch  (request,  *args,  **kwargs):  La  view  la  vista  - el  metodo  que  acepta 
un  argumento  request  mas  los  argumentos  pasados  y devuelve  una  respuesta 
HTTP. 

La  implementation  predeterminada  inspecciona  el  metodo  HTTP  y trata  de 
delegarlo  a el  metodo  que  coincida  con  la  petition  HTTP;  una  petition  GET 
sera  delegada  a un  metodo  get(),  una  POST  a un  post()  y asi  sucesivamente. 

Por  omision  una  petition  a HEAD  sera  delegada  al  metodo  get  () . Si  necesitas 
manejar  peticiones  HEAD  de  diferentes  formas  usa  GET  para  sobrescribir  el 
metodo  headQ. 

• http_method_not_allowed(request,  *args,  **kwargs):  Si  la  vista  es  llamada 

mediante  un  metodo  HTTP  no  soportado,  este  metodo  es  llamado  en  su  lugar. 
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La  implementation  predeterminada  devuelve  un  HttpResponseNotAllowed 
con  una  lista  de  metodos  permitidos  en  texto  piano. 

• options  (request,  *args,  **kwargs):  Maneja  la  respuesta  a las  peticiones  para 
los  verbos  OPTIONS  HTTP.  Devuelve  una  lista  de  nombres  de  metodos  HTTP 
permitidos  para  las  vistas. 


Renderizar  una  plantilla  con  TemplateView 
Clase:  django.views.generic.base.TemplateView 

Renderiza  una  plantilla  dada,  con  el  contexto  que  contiene  los  parametros 
capturados  en  la  URL. 

Ancestros  (MRO) 

Esta  vista  hereda  metodos  y atributos  de  las  siguientes  vistas: 

• django.views.generic.base.TemplateResponseMixin 

• django.views.generic.base.ContextMixin 

• django.views.generic.base.View 

Flujo  de  metodos: 

1.  dispatch  () 

2.  http_method_not_allowed() 

3.  get_context_data() 


Ejemplo: 

Para  mostrar  una  pagina  de  bienvenida  que  muestre  los  ultimos  5 libros  publicados 
en  la  base  de  datos,  usamos  la  clase  TemplateView  directamente  podriamos  hacerlo 
asi: 


views . py 


from  django.views. generic. base  import  TemplateView 
from  biblioteca.models  import  Libro 

class  PaginaBienvenida(TemplateView): 

template_name  = "bienvenida.html" 

def  get_context_data(self,  **kwargs): 

context  = sup(  (PaginaBienvenida,  self).get_context_data(**kwargs) 
context['ultimosJibros']  = Libro. objects. all()[:5] 
return  context 


Despues  solo  la  enlazamos  a su  respectiva  URL: 
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urls .py 


from  django.conf.urls  import  url 

from  biblioteca. views  import  PaginaBienvenida 

urlpatterns  = [ 

url(r'A$',  PaginaBienvenida. as_view(),  name- bienvenidos'), 

] 

Atributos 

Rellena  (A  traves  de  la  clase  ContextMixin)  con  los  argumentos  clave,  capturados  del 
patron  URL  que  sirve  la  vista. 


Redirigir  a otra  URL  mediante  RedirectView 
Clase:  django.views.generic.base. RedirectView 
Esta  vista  redirige  a otra  URL. 

La  URL  dada  puede  contener  un  formato  de  estilo  tipo  diccionario,  que  sera 
intercalado  contra  los  parametros  capturados  en  la  URL.  Ya  que  el  intercalado  de 
palabras  claves  se  hace  siempre  (incluso  si  no  se  le  pasan  argumentos),  por  lo  que 
cualquier  caracter  como  “%”  (un  marcador  de  position  en  Python)  en  la  URL  debe 
ser  escrito  como  “%%”  de  modo  que  Python  lo  convierta  en  un  simple  signo  de 
porcentaje  en  la  salida. 

Si  la  URL  pasada  como  parametro  es  None,  Django  retornara  un  mensaje  de  error 
410  (“Gone”  segun  el  estandar  HTTP). 

Ancestros  (MRO) 

Esta  vista  hereda  metodos  y atributos  de  las  siguientes  vistas: 

• django.views.generic.base.View 

Flujo  de  metodos: 

1.  dispatch!) 

2.  http_method_not_allowed() 

3.  get_redirect_url() 

Ejemplo: 

Supongamos  que  queremos  redirecionar  a nuestros  usuarios  a una  pagina  que 
actualiza  un  ficticio  contador  de  libros,  despues  de  que  visiten  una  pagina  de  detalles: 


views . py 


from  django. shortcuts  import  get_object_or_404 
from  django.views.generic.base  import  RedirectView 

from  biblioteca.models  import  Libro 

class  RedirecionarContadorLibros(RedirectView): 
permanent  = False 
query_string  = 
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pattern_name  = 'detalles-libro' 

def  get_redirect_url(self,  *args,  **kwargs): 

libro  = get_object_or_404(Libro,  pk=kwargs['pk']) 
libro.update_counter() 

return  s (RedirecionarContadorLibros,  lif).get_redirect_url(*args,  **kwargs) 


urls .py 


from  django.conf.urls  import  url 

from  django.views. generic. base  import  RedirectView 

from  biblioteca. views  import  RedirecionarContadorLibros,  DetalleLibros 
urlpatterns  = [ 

url(r'Acontador/(?P<pk>[0-9]+)/$',  RedirecionarContadorLibros. as_viewO, 
name-contador-libros'), 

url(r'Adetalles/(?P<pk>[0-9]+)/$',  DetalleLibros. as_view(), 
name='detalles-libro'), 

url(r'Ago-to-django/$',  RedirectView.as_view(url- http://djangoproject.com'), 
name='go-to-django'), 


Atributos 

• url  La  URL  a redirecionar,  como  una  cadena  o string.  O None  para  lanzar  un 
error  4 10  (Gone). 

• pattern_name:  El  nombre  de  el  patron  URL  para  redireccionamiento.  El 
redireccionamiento  puede  hacerse  usando  los  mismos  argumentos:  args  y 
kwargs  que  son  pasados  en  la  vistas. 

• Permanent:  Indica  si  el  redireccionamiento  deberia  ser  permanente,  La  unica 
diferencia  aqui  es  el  codigo  del  estatus  HTTP  que  devuelve.  Si  es  True,  el 
redirecionamiento  usara  un  codigo  de  estatus  301.  Si  es  False,  el  codigo  de 
estatus  sera  302.  El  valor  predeterminado  para  permanent  es  True. 

• query_string:  Indica  si  se  le  pasa  la  cadena  de  consulta  GET  a la  nueva 
localization.  Si  es  True,  la  cadena  de  consulta  es  agregada  a la  URL.  Si  es  False 
la  cadena  de  consulta  es  descartada.  El  valor  predeterminado  para 
query_string  es  False. 


Metodos 

• get_redirect_url(*args,  **kwargs)\  Construye  la  URL  del  objetivo,  para  el 
cambio  de  direction. 

La  implementation  predeterminada  usa  el  atributo  url  cuando  comienza 
como  una  cadena  y optimiza  la  expansion  de  los  nombres  de  parametros  % 
capturados  en  la  cadena,  usando  los  nombres  de  grupos  capturados  en  la 
URL. 
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Si  la  url  no  esta  establecido,  get_redirect_url()  trata  de  usar  el  inverso  de 
pattern_name  usando  los  valores  capturados  en  la  URL  (usando  nombres  y 
nombres  de  grupos) 

Si  la  petition  de  query_string,  es  agregada  a la  cadena  de  consulta  para  general 
la  URL.  La  subclase  puede  implementar  cualquier  comportamiento  que  desee, 
mientras  que  el  metodo  devuelva  un  redireccionamiento  listo  para  una 
cadena  de  una  URL. 


Vistas  de  listado/detalle 


Las  vistas  genericas  basadas  en  clases  de  listados/detalle  (que  residen  en  el  modulo 
django. views. generic)  se  encargan  de  la  habitual  tarea  de  mostrar  una  lista  de 
elementos  por  un  lado  (el  listado)  y una  vista  individual  para  cada  uno  de  los 
elementos  (el  detalle) 


Listas  de  objetos:  ListView 

Clase:  django. views. generic.list.ListView 

Una  pagina  que  representa  una  lista  de  objetos. 

Mientras  esta  vista  es  ejecutada  con  self.objecLjisl  contiene  una  lista  de  objetos 
(usualmente,  pero  no  necesariamente  un  queryset)  sobre  los  que  la  vista  esta 
operando. 

Ancestros  (MRO) 

Esta  vista  hereda  metodos  y atributos  de  las  siguientes  vistas: 

• django.views.generic.list.MultipleObjectTemplateResponseMixin 

• django.views.generic.base.TemplateResponseMixin 

• django.views.generic.list.BaseListView 

• django.views.generic.list.MultipleObjectMixin 

• django.views.generic.base.View 

Flujo  de  metodos: 

1.  dispatch!) 

2.  http_method_not_allowed() 

3.  get_template_names() 

4.  get_queryset() 

5.  get_context_object_name() 

6.  get_context_data() 

7.  get() 

8.  render_to_response() 

La  clase  ListView  usa  la  clase  BaseListView,  al  igual  que  las  vistas  que  necesitan 
presentar  una  lista  de  objetos. 
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Clase:  django. views. generic.list.BaseListView 

Una  vista  base  para  mostrar  una  lista  de  objetos,  No  esta  pensada  para  ser  usada 
directamente,  pero  puede  usarse  como  una  clase  padre  para 
django.  vie  ws.  gene  vie.  list.  List  Vie  w o Iras  vistas  que  representen  una  lista  de  objetos. 

Ancestros  (MRO) 


Esta  vista  hereda  metodos  y atributos  de  las  siguientes  vistas: 

• django.views.generic.list.MultipleObjectMixin 

• django.views.generic.base.View 

Metodos 

get{request,  *args,  **kwargs)\  Agrega  objecljist  al  contexto.  Si  el  atributo 
allow_empty  es  True  muestra  una  lista  vacia.  Si  el  atributo  allow_empty  es  False  lanza 
un  error  404. 

Ejemplo: 

Si  consideramos  el  objeto  Autor  tal  y como  se  definio  en  el  capitulo  5,  podemos  usar 
la  vista  ListView  para  obtener  un  listado  sencillo  de  todos  los  autores  usando  la 
siguiente  vista  generica  (usando  una  clase)  y su  respectiva  URLconf: 


biblioteca/views .py 


from  django.views. generic  import  ListView 
from  biblioteca.models  import  Autor 

# El  unico  requerimiento  es  un  queryset  o modelo. 
class  ListaAutores(ListView): 
model  = Autor 


biblioteca/urls .py 


from  django. conf.urls  import  url 

from  biblioteca. views  import  ListaAutores 

# Enlazamos  la  vista  usando  el  metodo  as_view() 

urlpatterns  = [ 

url(r'Aautores/$',  ListaAutores. as_view()), 

] 


templates/biblioteca/autor_list . html 


<hl>Lista  de  Autores</hl> 

<ul> 

{%  for  autor  in  objeetjist  %} 

<li><a  href="{%  url  'detalles-autores'  autor. id  %}">{{  autor. nombre  }} 
{{ autor. apellidos  }}</li> 

{%  empty  %} 

<li>No  hay  autores  registrados.</li> 

{%  endfor  %} 

</ul> 
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La  vista  ListView  usa  el  metodo  interno  get_absolute_url()  de  el  modelo  para 
enlazar  la  url  y la  vista  detallada  de  un  objeto  DetailView,  de  la  siguiente  forma(De  lo 
contrario  lanzara  una  exception): 


biblioteca/models . py 


from  django.core.urlresolvers  import  reverse 
from  django.db  import  models 

# La  clase  que  define  al  modelo  autor 

class  Autoi  (models. Model): 

nombre  = models.  CharField(max_length=  0) 

# ... 

# Muestra  los  detalles  del  objeto 

def  get_absolute_url(self): 

return  reverse('detalles-autores',  args=[self.pk]) 

Argumentos  obligatorios 

• queryset:  Un  QuerySet  de  los  objetos  a listar  (Vease  la  tabla  C-l)  o un  model: 
El  modelo  del  cual  la  vista  mostrara  los  datos,  como  en  el  ejemplo  anterior, 
model  = Autor  es  equivalente  a usar  un  queryset  = Autor.objects.allO 

Argumentos  opcionales 

• paginatejby:  (Paginacion)  es  un  numero  entero  que  especifica  cuantos 
objetos  se  deben  mostrar  en  cada  pagina.  Segun  se  especifique  en  este 
parametro,  los  resultados  seran  paginados,  de  forma  que  se  distribuiran  por 
varias  paginas  de  resultado.  La  vista  determinara  que  pagina  de  resultados 
debe  mostrar  o bien  desde  un  parametro  page  incluido  en  la  URL  (via  Get)  o 
mediante  una  variable  page  especificada  en  el  URLconf.  En  cualquiera  de  los 
dos  casos,  el  indice  comienza  en  cero.  En  la  siguiente  section  hay  una  nota 
sobre  paginacion  donde  se  explica  con  un  poco  mas  de  detalle  este  sistema. 

• template_name:  (Nombre  de  la  plantilla)  Si  no  se  ha  especificado  el 
parametro  optional  template_name,  la  vista  usara  una  plantilla  llamada 
<app_label>/<modeLname>_list.html.  Tanto  la  etiqueta  de  la  aplicacion 
como  la  etiqueta  del  modelo  se  obtienen  del  parametro  queryset.  La  etiqueta 
de  aplicacion  es  el  nombre  de  la  aplicacion  en  que  se  ha  definido  el  modelo,  y 
la  etiqueta  de  modelo  es  el  nombre,  en  minusculas,  de  la  clase  del  modelo. 

En  el  ejemplo  anterior,  tendriamos  que  el  queryset  seria  Autor.objects.allO, 
por  lo  que  la  etiqueta  de  la  aplicacion  sera  biblioteca  y el  nombre  del  modelo 
es  autor.  Con  esos  datos,  el  nombre  de  la  plantilla  a utilizar  por  defecto  sera 
biblioteca/autorjist.html. 

• contex_object_name:  El  nombre  del  contexto  a usar  en  las  plantillas,  si  no  se 
define  uno,  se  usara  el  predeterminado  que  es:  “ object_lisf 

Ademas  de  los  valores  que  se  puedan  haber  definido  en  el  contexto,  la  plantilla 
tendra  los  siguientes  valores: 
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• object_list:  La  lista  de  los  objetos.  El  nombre  de  la  variable  viene  determinado 
por  el  parametro  template_object_name,  y vale  'object'  por  defecto.  Si  se 
definiera  template_object_name  como  'foo',  el  nombre  de  esta  variable  seria 
foojist. 

• is_paginated:  Un  valor  booleano  que  indicara  si  los  resultados  seran 
paginados  o no.  Concretamente,  valdra  False  si  el  numero  de  objetos 
disponibles  es  inferior  o igual  a paginate_by. 

Si  los  resultados  estan  paginados,  el  contexto  dispondra  tambien  de  estas 
variables: 

• results_per_page:  El  numero  de  objetos  por  pagina.  (Su  valor  es  el  mismo  que 
el  del  parametro  paginate  Jby). 

• has_next:  Un  valor  booleano  indicando  si  hay  una  siguiente  pagina. 

• has_previous:  Un  valor  booleano  indicando  si  hay  una  pagina  previa. 

• page:  El  numero  de  la  pagina  actual,  siendo  1 la  primera  pagina. 

• next:  El  numero  de  la  siguiente  pagina.  Incluso  si  no  hubiera  siguiente  pagina, 
este  valor  seguira  siendo  un  numero  entero  que  apuntaria  a una  hipotetica 
siguiente  pagina.  Tambien  utiliza  un  indice  basado  en  1,  no  en  cero. 

• previous:  El  numero  de  la  anterior  pagina,  usando  un  indice  basado  en  1,  no 
en  cero. 

• pages:  El  numero  total  de  paginas. 

• hits.  El  numero  total  de  objetos  en  tod  as  las  paginas,  no  solo  en  la  actual. 


□ Una  nota  sobre  pagination: 


Si  se  utiliza  el  parametro  paginate_by,  Django  paginara  los  resultados.  Puedes  indicar 
que  pagina  visualizar  usando  dos  metodos  diferentes: 

1.  Usar  un  parametro  page  en  el  URLconf. 

2.  Pasar  el  numero  de  la  pagina  mediante  un  parametro  page  en  la  URL. 

En  ambos  casos,  page  es  un  indice  basado  en  1,  lo  que  significa  que  la  primera 
pagina  siempre  sera  la  numero  1,  no  la  numero  0. 


Listas  de  objetos:  DetailView 
Clase:  django.views.generic.detail. DetailView 

Esta  vista  proporciona  una  representation  individual  de  los  “detalles”  de  un  objeto. 
Cuando  esta  vista  es  ejecutada  self.object  contiene  un  objeto  sobre  el  que  la  vista 
opera. 
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Ancestros  (MRO) 

Esta  vista  hereda  metodos  y atributos  de  las  siguientes  vistas: 


• django.views. generic. detail.SingleObjectTemplateResponseMixin 

• django.views. generic.base.TemplateResponseMixin 

• django.views. generic. detail.BaseDetailView 

• dj  ango  .views . generic . detail.  SingleOb  jectMixin 

• django.views. generic.base.View 

Flujo  de  metodos: 

1.  dispatch  () 

2.  http_method_not_allowed() 

3.  get_template_names() 

4.  get_slug_field() 

5.  get_queryset() 

6.  get_object() 

7.  get_context_object_name() 

8.  get_context_data() 

9.  get() 

10.  render_to_response() 


Ejemplo: 

Siguiendo  con  el  ejemplo  anterior,  podemos  anadir  una  vista  de  detalle  de  cada  autor 
modificando  el  URLconf  y pasandole  un  contexto  extra  ahora,  de  la  siguiente  manera: 


biblioteca/views .py 


from  django.views. generic. detail  import  DetailView 
from  django. utils  import  timezone 

from  biblioteca.models  import  Autor 

class  DetalleAutores(DetailView): 

model  = Autor 

# Le  agregamos  un  contexto  extra  'ahora',  que  muestra  la  fecha  actual. 

def  get_context_data(self,  **kwargs): 

context  = (DetalleAutores,  ;!i).get_context_data(**kwargs) 
context['ahora']  = timezone. now() 
return  context 


biblioteca/urls .py 


from  django. conf.urls  import  url 

from  biblioteca. views  import  DetalleAutores 

urlpatterns  = [ 

url(r'Adetalle/autores/(?P<pk>[0-9]+)/$',  DetalleAutores. as_view(), 
name- detalles-autores' ), 
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templates/biblioteca/autor_detail . html 


{%  extends  "base.html"  %} 

{%  block  content  %} 

<hl>{{  object. nombre  }}{{  object.apellidos}}</hl> 

<ul> 

<li>Email:  { object. email  }}</li> 

<li>Ultimo  acceso:  object. ultimo_acceso  }}</li> 

<li>Fecha:  {{ ahora|date  }}</li> 

</ul> 

{%  endblock  %} 

Argumentos  obligatorios 

• queryset:  Un  QuerySet  que  sera  usado  para  localizar  el  objeto  a mostrar  o un 
model  (vease  la  Tabla  C-l). 

• object_id:  El  valor  de  la  clave  primaria  del  objeto  a mostrar.  En  el  ejemplo 
anterior  usamos  pk  para  capturar  la  clave  primaria  del  objeto  en  la  URL,  para 
pasarsela  a la  clase  vista  o puedes  usar: 

slug:  La  etiqueta  o slug  del  objeto  en  cuestion.  Si  se  usa  este  sistema  de 
identification,  hay  que  emplear  obligatoriamente  el  argumento  slug_fleld 
(que  se  explica  en  la  siguiente  section). 


Argumentos  opcionales 

• slug_field:  El  nombre  del  atributo  del  objeto  que  contiene  el  slug.  Es 
obligatorio  si  estas  usando  el  argumento  slug,  y no  se  debe  usar  si  estas 
usando  el  argumento  object_id. 

• template_name_field:  El  nombre  de  un  atributo  del  objeto  cuyo  valor  se 
usara  como  el  nombre  de  la  plantilla  a utilizar.  De  esta  forma,  puedes 
almacenar  en  tu  objeto  la  plantilla  a usar. 

En  otras  palabras,  si  tu  objeto  tiene  un  atributo  'the_template'  que  contiene  la 
cadena  de  texto  ' foo.html',  y defines  template_name_field  para  que  valga 
'the_template',  entonces  la  vista  generica  de  este  objeto  usara  como  plantilla 
'foo.html1. 

Si  el  atributo  indicado  por  template_name_field  no  existe,  se  usaria  el 
indicado  por  el  argumento  template_name.  Es  un  mecanismo  un  poco 
enmaranado,  pero  puede  ser  de  mucha  ayuda  en  algunos  casos. 

Nombre  de  la  plantilla 

• Si  no  se  especifican  template_name  ni  template_name_field,  se  usara  la 
plantilla  <app_label>/<model_name>_detail.html,  como  el  nombre  de  la 
plantilla. 
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Atributos  de  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  definido  en  el  contexto,  la  plantilla  tendra 
los  siguientes  valores: 

• object;  El  objeto.  El  nombre  de  esta  variable  puede  ser  distinto  si  se  ha 
especificado  el  argumento  context_object_name,  cuyo  valor  es  'object'  por 
defecto.  Si  definimos  context_object_name  como  ’foo’,  el  nombre  de  la 
variable  sera  foo. 


Vistas  genericas  para  Crear/Modificar/Borrar 
Clase:  django.views.generic.dates 

El  modulo  django.views. generic. edit,  contiene  una  serie  de  funciones  para  crear, 
modificar  y borrar  objetos. 

Las  vistas  son  las  siguientes: 

• dj  ango  .views . generic . edit.  Fo  r mVie  w 

• dj  ango  .views . generic . edit . CreateVie  w 

• dj  ango  .views  .generic . edit . Update  Vie  w 

• django.views. generic. edit.DeleteView 

Todas  estas  vistas  presenta  formularios  si  se  acceden  con  GET  y realizan  la 
operation  solicitada  (crear/modificar/borrar)  si  se  acceden  con  POST. 

Estas  vistas  tienen  un  concepto  muy  simple  de  la  seguridad.  Aunque  aceptan  un 
argumento  llamado  login_required,  que  restringe  el  acceso  solo  a usuarios 
identiflcados,  no  hacen  nada  mas.  Por  ejemplo,  no  comprueban  que  el  usuario  que 
esta  modilicando  un  objeto  sea  el  mismo  usuario  que  lo  creo,  ni  validaran  ningun 
tipo  de  permisos. 

En  cualquier  caso,  la  mayor  parte  de  las  veces  se  puede  conseguir  esta 
funcionalidad  simplemente  escribiendo  un  pequeno  recubrimiento  alrededor  de  la 
vista  generica.  Para  mas  information  sobre  esta  tecnica,  vease  el  capltulo  11. 

Mostrar  formularios  con:  FormView 

Clase:  django. views. generic.edit. FormView 

Una  vista  que  muestra  un  formulario.  Si  existen  errores  vuelve  a mostrar  el 
formulario  con  los  errores  de  validation;  si  esta  tiene  exito  redirecciona  a la  nueva 
URL. 

Ancestros  (MRO) 

Esta  vista  hereda  metodos  y atributos  de  las  siguientes  vistas: 

• django.views. generic.base.TemplateResponseMixin 

• django.views. generic. edit.BaseForm  View 

• dj  ango  .views . generic  .edit.  FormMixin 

• django.views. generic. edit.ProcessForm  View 

• dj  ango  .views . generic  .base  .Vie  w 
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Ejemplo: 

Supongamos  que  queremos  mostrar  un  sencillo  formulario  de  contactos: 


forms . py 


from  django  import  forms 

class  FormularioContactos(forms.Form): 

nombre  = forms. CharField() 

mensaje  = forms.  CharField(widget=forms.Textarea) 
def  send_email(self): 

# Envia  el  email  usando  el  diccionario  self.cleaned_data 
pass 


views . py 


from  django. views. generic. edit  import  FormView 
from  biblioteca.forms  import  FormularioContactos 

class  VistaContactos(FormView): 

template_name  = 'contactos.html' 
form_class  = FormularioContactos 
success_url  = '/gracias/' 

def  form_valid(self,  form): 

# Este  metodo  es  llamado  cuando  el  formulario  valida  los  datos 

# A enviar.  Debe  devolver  un  FlttpResponse 

form.send_email() 

return  su[  (VistaContactos,  lf).form_valid(form) 


contactos . html 


<form  action=""  method="post">{%  csrf_token  %} 
{{ form.as_p  }} 

<input  type="enviar"  value="Enviar  mensaje"  /> 
</form> 


Vista  de  creacion  de  objetos:  CreateView 
Clase:  django. views. generic.edit.CreateView 

Esta  vista  presenta  un  formulario  que  permite  la  creacion  de  un  objeto.  Cuando  se 
envian  los  datos  del  formulario,  la  vista  se  vuelve  a mostrar  si  se  produce  algun  error 
de  validacion  (incluyendo,  por  supuesto,  los  mensajes  pertinentes)  o,  en  caso  de  que 
no  se  produzca  ningun  error  de  validacion,  guarda  el  objeto  en  la  base  de  datos. 

Ancestros  (MRO) 

Esta  vista  hereda  los  metodos  y atributos  de  las  siguientes  vistas: 

• django.views. generic. detail.SingleObjectTemplateResponseMixin 

• django.views. generic.base.TemplateResponseMixin 
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• django.views. generic. edit.BaseCreateView 

• dj  ango  .views . generic . edit . Mo  delF  ormMixin 

• django.views. generic. edit.FormMixin 

• dj  ango  .views . generic . detail.  SingleOb  jectMixin 

• django.views. generic. edit.ProcessFormView 

• django.views.generic.base.View 

Atributos 

• template_name_suffix:  La  pagina  CreateView  a mostrar,  mediante  una 

petition  GET  que  usa  como  template_name_suffix  a _form.  Por  ejemplo 
cambiando  este  atributo  por  _create_form  para  una  vista  para  crear  objetos, 
por  ejemplo  para  el  modelo  Autor  ocasionara  que  el  valor  predeterminado  de 
template_name  sea  “biblioteca/autor_create_form.html”. 

• object:  Cuando  se  usa  CreateView  se  tiene  acceso  a self.object,  el  cual  es  el 
objeto  creado.  Si  el  objeto  no  ha  sido  creado,  el  valor  sera  None. 

Ejemplo: 

Si  quisieramos  permitir  al  usuario  que  creara  nuevos  autores  en  la  base  de  datos, 

podriamos  hacer  algo  como  esto: 


views . py 


from  django.views. generic. edit  import  CreateView 
from  biblioteca.models  import  Autor 

class  CrearAutor(CreateView): 
model  = Autor 
fields  = ['nombre,  apellidos] 


autor  form.html 


<form  action-'"  method="post">{%  csrf_token  %} 

{{ form.as_p }} 

<input  type="enviar"  value="Crear"  /> 

</form> 

Argumentos  obligatorios 

• model:  El  modelo  Django  del  objeto  a crear. 


Observa  que  esta  vista  espera  el  modelo  del  objeto  a crear,  y no  un  QuerySet 
como  el  resto  de  las  vistas  que  se  han  visto  previamente. 


Nombre  de  la  plantilla 

Si  no  se  ha  especificado  ningun  valor  en  template_name  la  vista  usara  como  plantilla 
<app_label>/<model_name>_form.html. 
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Atributos  de  la  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  definido  en  el  contexto,  la  plantilla  tendra 
los  siguientes  valores: 

• form:  Una  instancia  de  la  clase  ModelForm,  que  representa  el  formulario  a 
utilizar.  Esto  te  permite  referirte  de  una  forma  sencilla  a los  campos  del 
formulario  desde  la  plantilla.  Por  ejemplo,  si  el  modelo  consta  de  dos 
atributos,  nombre  y direccion: 


Vista  para  modificar  objetos:  UpdateVieiv 

Clase:  django.views.generic.edit.UpdateView 

Esta  vista  muestra  un  formulario  para  editar  un  objeto  existente,  vuelve  a mostrar  el 
formulario  en  caso  de  errores  de  validacion  (si  los  hay)  y permite  guardar  los  cambios 
en  el  objeto.  Usa  un  formulario  generado  automaticamente  por  el  modelo  de  la  clase 
del  objeto  (A  menos  que  se  especiflque  manualmente  una  clase  para  el  formulario). 

Ancestros  (MRO) 

Esta  vista  hereda  los  metodos  y atributos  de  las  siguientes  vistas: 

• django.views. generic. detail.SingleObjectTemplateResponseMixin 

• django.views. generic.base.TemplateResponseMixin 

• dj  ango  .views . generic . edit . B aseUpdate  View 

• dj  ango  .views . generic . edit . Mo  delF  ormMixin 

• dj  ango  .views  .generic . edit.  FormMixin 

• dj  ango  .views  .generic . detail.  SingleOb  jectMixin 

• django.views. generic. edit.ProcessFormView 

• dj  ango  .views . generic  .base  .Vie  w 

Atributos 

• template_name_suffix:  La  pagina  UpdateView  a mostrar,  mediante  una 
peticion  GET  que  usa  como  template_name_suffix  a _form.  Por  ejemplo 
cambiando  este  atributo  por  _create_form  para  una  vista  para  actualizar 
objetos,  por  ejemplo  para  el  modelo  Autor  ocasionara  que  el  valor 
predeterminado  de  template_name  sea  'biblioteca/autor_create_form.htmr. 

• object:  Cuando  se  usa  UpdateView'  se  tiene  acceso  a "self.object,  el  cual  es 
el  objeto  modificado. 


Ejemplo: 

Siguiendo  con  el  ejemplo,  podemos  proporcionar  al  usuario  una  interfaz  de 
modificacion  de  los  datos  de  un  autor  con  el  siguiente  codigo  en  el  URLconf: 
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views . py 


from  django. views. generic. edit  import  UpdateView 
from  biblioteca.models  import  Autor 

class  ModificarAutor(UpdateView): 
model  = Autor 

fields  = ['nombre',  apellidos] 
template_name_suffix  = '_update_form' 


autor_update_f orm . html 


<form  action-'"  method="post">{%  csrf_token  %} 

{{ form,as_p }} 

<input  type-'submit"  value="Update"  /> 

</form> 

Argumentos  obligatorios 

• model:  El  modelo  Django  a editar.  Hay  que  prestar  atencion  a que  es  el 
modelo  en  sf,  y no  un  objeto  tipo  QuerySet. 

• object_id:  El  valor  de  la  clave  primaria  del  objeto  a modificar.  o bien  un  slug; 
El  slug  del  objeto  a modificar.  Si  se  pasa  este  argumento,  es  obligatorio 
tambien  el  argumento  slug_field. 

Argumentos  opcionales 

• slug_field:  El  nombre  del  campo  en  el  que  se  almacena  el  valor  del  slug  del 
sujeto.  Es  obligado  usar  este  argumento  si  se  ha  indicado  el  argumento  slug, 
pero  no  debe  especificarse  si  hemos  optado  por  identificar  el  objeto  mediante 
su  clave  primaria,  usando  el  argumento  object_id. 

Esta  vista  acepta  los  mismos  argumentos  opcionales  que  la  vista  de  creacion  y, 
ademas,  el  argumento  comun  template_object_name,  explicado  en  la  tabla  C-l. 

Nombre  de  la  plantilla 

Esta  vista  utiliza  el  mismo  nombre  de  plantilla  por  defecto  que  la  vista  de  creacion 
(<app_label>  / <model_name>_form.html) . 

Atributos  de  la  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  definido  en  el  contexto,  la  plantilla  tendra 
los  siguientes  valores: 

• form;  Una  instancia  de  ModelForm  que  representa  el  formulario  de  edicion 
del  objeto. 

• object:  El  objeto  a editar  (El  nombre  de  esta  variable  puede  ser  diferente  si  se 
ha  especificado  el  argumento  template_object_name). 
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Vista  de  borrado  de  objetos:  DeleteVieiv 
Clase:  django. views. generic.edit.DeleteView 

Una  vista  que  muestra  una  pagina  de  confirmacion  y borrado  de  un  objeto  existente. 
Esta  vista  es  muy  similar  a la  dos  anteriores:  crear  y modificar  objetos.  El  proposito  de 
esta  vista  es,  sin  embargo,  permitir  el  borrado  de  objetos. 

Si  la  vista  es  alimentada  mediante  GET,  se  mostrara  una  pantalla  de  confirmacion 
(del  tipo  “^Realmente  quieres  borrar  este  objeto?”).  Si  la  vista  se  alimenta  con  POST, 
el  objeto  sera  borrado  sin  conformation. 

Los  argumentos  son  los  mismos  que  los  de  la  vista  de  modification,  asi  como  las 
variables  de  contexto.  El  nombre  de  la  plantilla  por  defecto  para  esta  vista  es 
<app_label>/<model_name>_confirm_delete.html. 

Ancestros  (MRO) 

Esta  vista  hereda  los  metodos  y atributos  de  las  siguientes  vistas: 

• django.views. generic. detail.SingleObjectTemplateResponseMixin 

• django.views.  generic.base.TemplateResponseMixin 

• django.views. generic. edit.BaseDeleteView 

• dj  ango  .views . generic . edit.D  eletionMixin 

• dj  ango  .views . generic . detail.  BaseD  etailVie  w 

• dj  ango  .views . generic . detail.  SingleOb  jectMixin 

• dj  ango  .views . generic  .base  .Vie  w 

• template_name_suffix 

La  pagina  DeleteView  a mostrar,  mediante  una  peticion  GET  que  usa  como 
template_name_suffix  a _confirm_delete.  Por  ejemplo  cambiando  este  atributo  por 
_check_delete  para  una  vista  para  actualizar  objetos,  por  ejemplo  para  el  modelo 
Autor  ocasionara  que  el  valor  predeterminado  de  template_name  sea 
biblioteca/autor check_delete.html. 

Ejemplo: 

Supongamos  que  queremos  borrar  un  objeto  Autor,  esta  es  la  forma  en  la  que  lo 
podemos  hacer. 


biblioteca/views .py 


from  django. views. generic. edit  import  DeleteView 
from  django. core. urlresolvers  import  reversejazy 
from  biblioteca.models  import  Author 

class  BorrarAutor(DeleteView): 
model  = Autor 

success_url  = reversejazy('lista-autores') 


biblioteca/author  confirm  delete.html 


<form  action-'"  method="post">{%  csrf_token  %} 

<p>  ^Realmente  quieres  borrar  este  object  ] "?</p> 
<input  type-'enviar"  value="Confirmar"  /> 

</form> 
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Vistas  genericas  basadas  en  fechas 


Estas  vistas  genericas  basadas  en  fechas  se  suelen  utilizar  para  organizar  la  parte  de 
“archivo”  de  nuestro  contenido.  Los  casos  tipicos  son  los  archivos  por  ano/mes/dia 
de  un  periodico,  o el  archivo  de  una  bitacora  o blog. 

En  principio,  estas  vistas  ignoran  las  fechas  que  esten  situadas  en  el  futuro. 

Esto  significa  que  si  intentas  visitar  una  pagina  de  un  archivo  que  este  en  el  futuro, 
Django  mostrara  automaticamente  un  error  404  (“Pagina  no  encontrada”),  incluso 
aunque  hubiera  objetos  con  esa  fecha  en  el  sistema. 

Esto  te  permite  publicar  objetos  por  adelantado,  que  no  se  mostraran 
publicamente  hasta  que  se  llegue  a la  fecha  de  publication  deseada. 

Sin  embargo,  para  otros  tipos  de  objetos  con  fechas,  este  comportamiento  no  es  el 
deseable  (por  ejemplo,  un  calendario  de  proximos  eventos).  Para  estas  vistas, 
podemos  definir  el  argumento  allow_future  como  True  y de  esa  manera  conseguir 
que  los  objetos  con  fechas  futuras  aparezcan  (o  permitir  a los  usuarios  visitar  paginas 
de  archivo  “en  el  futuro”). 

Indice  de  archivo:  ArchivelndexView 
Clase:  django.views.generic.dates.ArchivelndexView 

Esta  vista  proporciona  un  indice  a nivel-superior  donde  se  muestran  los  “ultimos” 
objetos  (es  decir,  los  mas  recientes)  segun  la  fecha.  Los  objetos  con  fechas  en  el 
futuro  no  estan  incluidos,  a menos  que  se  establezca  el  atributo  allow_future  en  True. 

Ancestros  (MRO) 

• django.views.generic.list.MultipleObjectTemplateResponseMixin 

• django.views.generic.base.TemplateResponseMixin 

• django.views. generic. dates. BaseArchivelndexView 

• dj  ango  .views . generic . dates . B aseD  ateListView 

• django.views. generic.list.MultipleObjectMixin 

• dj  ango  .views  .generic . dates . D ateMixin 

• django.views. generic.base.View 


Atributos 

Ademas  del  contexto  ofrecido  por:  django.views. generic.list.MultipleObjectMixin  (via 
django .views. generic.dates.BaseDateListView),  el  contexto  de  las  plantillas  sera: 

• date_list;  Un  objeto  DateQuerySet  que  contiene  todos  las  anos  segun  los 
cuales  tengan  objetos  disponibles  de  acuerdo  al  queryset,  representado  como 
un  objeto  datetime.datetime  en  orden  descendiente. 

1.  Usa  de  forma  predeterminada  latest  para  el  context_object_name. 

2.  Usa  de  forma  predeterminada  _archive  para  el  sufijo 
template_name_suffix. 
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3.  Usa  de  forma  predeterminada  datejist  por  ano,  pero  puede  ser 
sobrescrito  a mes  o dia  usando  el  atributo  date_list_period.  Esto 
tambien  se  aplica  a las  vistas  de  las  subclases. 


Ejemplo: 

Supongamos  el  tipico  editor  que  desea  una  pagina  con  la  lista  de  sus  ultimos  libros 
publicados.  Suponiendo  que  tenemos  un  objeto  Libro  con  un  atributo  tipo, 
fecha_publicacion,  podemos  usar  la  vista  ArchivelndexView  para  resolver  este 
problema: 


biblioteca/urls .py 


from  django.conf.urls  import  url 

from  django. views. generic. dates  import  ArchivelndexView 
from  biblioteca.models  import  Libro 
urlpatterns  = [ 

url(r'Aultimos-libros/$',  ArchivelndexView.as_view(model=Libro, 
date_field="fecha_publicacion"),  name-'ultimosjibros"), 

] 


biblioteca/libro  archive.html 


<ul> 

{%  for  libros  in  latest  %} 

<li>{{  libros. fecha_publicacion  }}:  {{ libros. titulo  }}</li> 
{%  endfor  %} 

</ul> 


Argumentos  obligatorios 

• date_field:  El  nombre  de  un  campo  tipo  DateField  o DateTimeField  de  los 
objetos  que  componen  el  QuerySet.  La  vista  usara  los  valores  de  ese  campo 
como  referencia  para  obtener  los  ultimos  objetos. 

• queryset:El  QuerySet  de  objetos  que  forman  el  archivo  o el  model. 


Argumentos  opcionales 

• allow_future;  Un  valor  booleano  que  indica  si  los  objetos  “futuros”  (es  decir, 
con  fecha  de  referencia  en  el  futuro)  deben  aparecer  o no. 

Nombre  de  la  plantilla 

Si  no  se  ha  especificado  template_name,  se  usara  la  plantilla 
<app_label>/<model_name>_archive.html. 

Atributos  de  la  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  definido  en  el  contexto  de  la  plantilla 
tendra  los  siguientes  valores: 
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• date_list:  Una  lista  de  objetos  de  tipo  datetime.date  que  representarian  todos 
los  anos  en  los  que  hay  objetos,  de  acuerdo  al  queryset.  Vienen  ordenados  de 
forma  descendente,  los  anos  mas  recientes  primero. 

Por  ejemplo,  para  un  blog  que  tuviera  entradas  desde  el  ano  2003  hasta  el 
2006,  la  lista  contendra  cuatro  objetos  de  tipo  datetime.date,  uno  para  cada 
uno  se  esos  anos. 

• latest;  Los  ultimos  num_latest  objetos  en  el  sistema,  considerandolos 
ordenados  de  forma  descendiente  por  el  campo  date_field  de  referencia. 


Archivos  anuales:  YearArchiveView 


Clase:  django. views. generic.dates.BaseYearArchiveView 

Esta  vista  sirve  para  presentar  archivos  basados  en  anos.  Poseen  una  lista  de  los 
meses  en  los  que  hay  algun  objeto,  y pueden  mostrar  opcionalmente  todos  los 
objetos  publicados  en  un  ano  determinado.  Los  objetos  con  fechas  en  el  futuro  no 
estan  incluidos,  a menos  que  se  establezca  el  atributo  allow_future  e n True. 

Ancestros  (MRO) 

• django.views.generic.list.MultipleObjectTemplateResponseMixin 

• django.views.generic.base.TemplateResponseMixin 

• dj  ango  .views . generic . dates . B aseYearArchive  Vie  w 

• dj  ango  .views  .generic . dates . YearMixin 

• dj  ango  .views . generic . dates . B aseD  ateListView 

• django.views.generic.list.MultipleObjectMixin 

• dj  ango  .views  .generic . dates . D ateMixin 

• dj  ango  .views . generic  .base  .Vie  w 


Atributos 

• make_object_list:  Un  valor  booleano  que  especifica  si  debe  recuperar  la  lista 
completa  de  objetos  para  este  ano  y pasarsela  a la  plantilla.  Si  es  True  la  lista 
de  objetos  estara  disponible  en  el  contexto.  Si  es  'False,  el  queryset  usara  el 
valor  None  como  la  lista  de  objetos.  De  forma  predeterminada  esta  es  False. 

• get_make_object_list():  Determina  si  un  objeto  de  la  lista,  debe  devolverse 
como  parte  de  el  contexto.  Devuelve  de  forma  predeterminada 
make_object_list 


Atributos 

Ademas  del  contexto  ofrecido  por:  django.views.generic.list.MultipleObjectMixin  (a 
traves  de  django.views. generic. dates. BaseDateListView),  el  contexto  de  la  plantilla 
contendra: 
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• date_list:  Un  objeto  DateQuerySet  que  contiene  todos  los  meses  en  los  que 
hay  objetos  disponibles,  de  acuerdo  al  queryset,  representado  como  un  objeto 
datetime.datetime  en  orden  ascendente. 

• year:  Un  objeto  date  que  representa  el  ano  dado. 

• next_year:  Un  objeto  date  que  representa  el  primer  dia  de  el  siguiente  ano,  de 
acuerdo  al  allow_empty  y allow_future. 

• previous_year:  Un  objeto  date  que  representa  el  primer  dia  del  ano  previo,  de 
acuerdo  al  allow_empty  y allow_future. 

Usa  de  forma  predeterminada  _archive_year  como  el  nombre  del  sufijo  de 
plantilla  para  template_name_suffix. 

Ejemplo: 

Como  ejemplo,  vamos  a ampliar  el  ejemplo  anterior  incluyendo  una  vista  que 
muestre  todos  los  libros  publicados  en  un  determinado  ano: 


biblioteca/views .py 


from  django. views. generic. dates  import  YearArchiveView 
from  biblioteca.models  import  Libro 

class  LibrosAnuales(YearArchiveView): 
queryset  = Libro. objects. all() 
date_field  = "fecha_publicacion" 
make_object_list  = rue 
allow  future  = 


biblioteca/urls .py 


from  django. conf.urls  import  url 

from  biblioteca. views  import  LibrosAnuales 

urlpatterns  = [ 

url(r'A(?P<year>[0-9]{4})/$',  LibrosAnuales. as_view(), 
name="libros_anuales"), 

] 


biblioteca/libros_archive_year . html 


<ul> 

{%  for  fecha  in  datejist  %} 

<li>{{  fecha|date  }}</li> 

{%  endfor  %} 

</ul> 

<div> 

<hl>Todos  los  libros  del  {{ year|date:"Y"  }}</hl> 

{%  for  libros  in  objectjist  %} 

<p> 

{{ libros. titulo }}  - {{ libros.fecha_publicacion|date:"F  j,  Y" }} 

</p> 

{%  endfor  %} 

</div> 
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Argumentos  obligatorios 

• date_field:  Igual  que  en  ArchivelndexView  (Vease  la  seccion  previa) . 

• queryset:  El  QuerySet  de  objetos  archivados. 

• year:  El  ano,  con  cuatro  dlgitos,  que  la  vista  usara  para  mostrar  el  archivo 
(Como  se  ve  en  el  ejemplo,  normalmente  se  obtiene  de  un  parametro  en  la 
URL). 

Argumentos  opcionales 

• make_object_list:  Un  valor  booleano  que  indica  si  se  debe  obtener  la  lista 
completa  de  objetos  para  este  ano  y pasarsela  a la  plantilla.  Si  es  True,  la  lista 
de  objetos  estara  disponible  para  la  plantilla  con  el  nombre  de  objectjisl 
(Aunque  este  nombre  podria  ser  diferente;  vease  la  information  sobre 
object Jist  en  la  siguiente  explication  sobre  “Atributos  de  plantilla”).  Su  valor 
por  defecto  es  False. 

• allow_future:  Un  valor  booleano  que  indica  si  deben  incluirse  o no  en  esta 
vista  las  fechas  “en  el  futuro”. 

Nombre  de  la  plantilla 

Si  no  se  especifica  ningun  valor  en  name,  la  vista  usara  la  plantilla 

<appJabel>/<model_name>_archive_year.html. 

Atributos  de  la  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  definido  en  el  contexto  de  la  plantilla, 

tendra  los  siguientes  valores: 

• date_list:  Una  lista  de  objetos  de  tipo  datetime.date,  que  representan  todos 
los  meses  en  los  que  hay  disponibles  objetos  en  un  ano  determinado,  de 
acuerdo  al  contenido  del  queryset,  en  orden  ascendente. 

• year:  El  ano  a mostrar,  en  forma  de  cadena  de  texto  con  cuatro  dlgitos. 

• object_list:  Si  el  parametro  make_object_list  es  True,  esta  variable  sera  una 
lista  de  objetos  cuya  fecha  de  referencia  cae  en  en  ano  a mostrar,  ordenados 
por  fecha.  El  nombre  de  la  variable  depende  del  parametro 
template_object_name,  que  es  'object'  por  defecto.  Si  template_object_name 
fuera  'foo',  el  nombre  de  esta  variable  seria  foojist. 

Si  make_object  Jist  es  False,  objectjisl  sera  una  lista  vatia. 


Archivos  mensuales:  MonthArchiveView 

Clase:  django. views. generic.dates.BaseMonthArchiveView 

Esta  vista  proporciona  una  representation  basada  en  meses,  en  la  que  se  muestran 
todos  los  objetos  cuya  fecha  de  referencia  caiga  en  un  determinado  mes  y ano.  Los 
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objetos  con  fechas  en  el  futuro  no  estan  incluidos,  a menos  que  se  establezca  el 
atributo  allow_future  en  True. 

Ancestros  (MRO) 

• django.views.generic.list.MultipleObjectTemplateResponseMixin 

• django.views.generic.base.TemplateResponseMixin 

• dj  ango  .views  .generic . dates . B aseMo  nthArchiveView 

• dj  ango  .views  .generic . dates . YearMixin 

• dj  ango  .views  .generic . dates . M onthMixin 

• dj  ango  .views . generic . dates . B aseD  ateListView 

• django.views.generic.list.MultipleObjectMixin 

• dj  ango  .views  .generic . dates . D ateMixin 

• django.views.generic.base.View 

Atributos 

Ademas  del  contexto  ofrecido  por:  MultipleObjectMixin  (a  traves  de 

BaseDateListView),  el  contexto  de  la  plantilla  contendra: 

• date_list:  Un  objeto  DateQuerySet  que  contiene  todos  los  dias  que  contienen 
objetos  disponibles  en  el  mes  dado,  de  acuerdo  al  queryset  representado  por 
el  objeto  datetime. datetime  en  orden  ascendente. 

• month:  Una  objeto  de  la  clase  date  que  representa  en  mes  dado. 

• next_month:  Un  objeto  de  la  clase  date  que  representa  el  primer  dia  de  el 
siguiente  mes,  de  acuerdo  al  atributo  allow_empty  y allow_future. 

• previous_month:  Un  objeto  de  la  clase  date  que  representa  el  primer  dia  del 
mes  anterior,  de  acuerdo  al  atributo  allow_empty  y allow_future. 

Usa  de  forma  predeterminada  _archive_month  como  el  nombre  del  sufijo  de 
plantilla  para  template_name_suffix. 

Ejemplo 

Siguiendo  con  nuestro  ejemplo,  anadir  una  vista  mensual  a nuestra  aplicacion, 
deberfa  ser  algo  sencillo: 


biblioteca/views .py 


from  django. views. generic. dates  import  MonthArchiveView 
from  biblioteca.models  import  Libro 

class  LibrosPorMes(MonthArchiveView): 
queryset  = Libro. objects. all() 
date_field  = "fecha_publicacion" 
make_object_list  = 
allow  future  = rue 
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biblioteca/urls .py 


from  django.conf.urls  import  url 

from  biblioteca. views  import  LibrosPorMes 

urlpatterns  = [ 

# Ejemplo:  /2012/agosto/ 

url(r'A(?P<year>[0-9]{4})/(?P<month>[-\w]+)/$',  LibrosPorMes. as_view(), 
name="libros_mes"), 

# Ejemplo:  /2012/08/ 

url(r'A(?P<year>[0-9]{4})/(?P<month>[0-9]+)/$', 

LibrosPorMes. as_view(month_format='%m),  name="libros_mes_numerico"), 

] 


libro  archive  month.html 


<ul> 

{%  for  libro  in  objectjist  %} 

<li>{{  libro.fecha_publicacion|date:"F  j,  Y" }}:  {{ libro. titulo  }}</li> 
{%  endfor  %} 

</ul> 

<p> 

{%  if  previous_month  %} 

Mes  anterior:  {{  previous_month|date:"F  Y" }} 

{%  endif  %} 

{%  if  next_month  %} 

Mes  siguiente:  { next_month|date  'F  Y" }} 

{%  endif  %} 

</p> 


Argumentos  obligatorios 

• year:  El  ano  a mostrar,  en  forma  de  cadena  de  texto  con  cuatro  dfgitos. 

• month:  El  mes  a mostrar,  formateado  de  acuerdo  con  el  argumento 
month_format. 

• queryset:  El  QuerySet  de  objetos  archivados. 

• date_field:  El  nombre  del  campo  de  tipo  DateField  o DateTimeField  en  el 
modelo  usado  para  el  QuerySet  que  se  usara  como  fecha  de  referenda. 

Argumentos  opcionales 

• month_format:  Una  cadena  de  texto  que  determina  el  formato  que  debe  usar 
el  parametro  month.  La  sintaxis  a usar  debe  coincidir  con  la  de  la  funcion 
time.strftime  (La  documentation  de  esta  funcion  se  puede  consultar  en 
http://www.djangoproject.eom/r/python/strftime/).  Su  valor  por  defecto  es 
“%b”,  que  significa  el  nombre  del  mes,  en  ingles,  y abreviado  a tres  letras  (Es 
decir,  “jan”,  “feb”,  etc.).  Para  cambiarlo  de  forma  que  se  usen  numeros,  hay 
que  utilizar  como  cadena  de  formato  “%m”. 
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• allow_future;  Un  valor  booleano  que  indica  si  deben  incluirse  o no  en  esta 
vista  las  fechas  “en  el  futuro”,  igual  al  que  hemos  visto  en  otras  vistas 
anteriores. 

Nombre  de  la  plantilla 

Si  no  se  especifica  ningun  valor  en  template_name,  la  vista  usara  como  plantilla 
<app_label>  / <model_name>_archive_month.html. 

Atributos  de  la  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  delinido  en  el  contexto,  la  plantilla 
contendra  los  siguientes  valores: 

• month:  Un  objeto  de  tipo  datetime.date  que  representa  el  mes  y ano  de 
referenda. 

• next_month:  Un  objeto  de  tipo  datetime.date  que  representa  el  primer  dla  del 
siguiente  mes.  Si  el  siguiente  mes  cae  en  el  futuro,  valdra  None. 

• previous_month:  Un  objeto  de  tipo  datetime.date  que  representa  el  primer 
dia  del  mes  anterior.  Al  contrario  que  next_month,  su  valor  nunca  sera  None. 

• object_list:  Una  lista  de  objetos  cuya  fecha  de  referencia  cae  en  en  ano  y mes 
a mostrar.  El  nombre  de  la  variable  depende  del  parametro 
template_object_name,  que  es  'object'  por  defecto. 

Si  template_object_name  fuera  'foo',  el  nombre  de  esta  variable  seria  foojist. 


Archivos  semanales:  WeelcArchiveView 
Clase:  django.views.generic.dates.BaseWeekArchiveView 

Esta  vista  muestra  todos  los  objetos  de  una  semana  determinada.  Los  objetos  con 
fechas  en  el  futuro  no  estan  incluidos,  a menos  que  se  establezca  el  atributo 
allow_future  en  True. 

Ancestros  (MRO) 

• django.views.generic.list.MultipleObjectTemplateResponseMixin 

• django.views.generic.base.TemplateResponseMixin 

• dj  ango  .views  .generic . dates . B aseWeekArchive  View 

• dj  ango  .views  .generic . dates . YearMixin 

• django.views.  generic.  dates.WeekMixin 

• dj  ango  .views . generic . dates . B aseD  ateListView 

• django.views. generic.list.MultipleObjectMixin 

• dj  ango  .views  .generic . dates . D ateMixin 

• dj  ango  .views . generic  .base  .Vie  w 
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Atributos 

Ademas  del  contexto  ofrecido  por:  MultipleObjectMixin  (a  traves  de 

BaseDateListView),  el  contexto  de  la  plantilla  contendra: 

• week:  Una  objeto  date  que  representa  el  primer  dia  de  la  semana  dada. 

• next_week:  Un  objeto  date  que  representa  el  primer  dia  de  la  siguiente 
semana,  de  acuerdo  al  atributo  allow_empty  y allow_future. 

• previous_week:  Un  objeto  date  que  representa  el  primer  dia  de  la  semana 
previa,  de  acuerdo  a allow_empty  y allow_future. 

Usa  de  forma  predeterminada  _archive_week  como  el  nombre  del  sufijo  de 
plantilla  para  template_name_suffix. 


Nota:  Por  consistencia  con  las  Librerias  de  manejo  de  fechas  de  Python,  Django 
asume  que  el  primer  dia  de  la  semana  es  el  domingo. 


Ejemplo: 

Siguiendo  con  nuestro  ejemplo,  anadir  una  vista  semanal  a nuestra  aplicacion,  no 
deberia  ser  muy  complicado. 


biblio teca/views . py . html 


from  django. views. generic. dates  import  WeekArchiveView 
from  biblioteca.models  import  Libro 

class  LibrosSemanales(WeekArchiveView): 

queryset  = Libro. objects. all() 
date_field  = "fecha_publicacion" 

make_object_list  = 
week_format  = "%W" 
allow  future  = 


biblioteca/urls .py 


from  django. conf.urls  import  url 

from  biblioteca. views  import  LibrosSemanales 

urlpatterns  = [ 

# Example:  /2012/week/23/ 

url(r'A(?P<year>[0-9]{4})/week/(?P<week>[0-9]+)/$', 
LibrosSemanales.as_view(), 
name="libros-semanales'  ’), 

] 


article  archive  week.html 


<hl>Semana  {{ week|date:'W'  }}</hl> 

<ul> 

{%  for  libros  in  objectjist  %} 

<li>{{  libros. fecha_publicacion|date  'F  j,  Y" }}:  {{ libro. titulo  }}</li> 
{%  endfor  %} 
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</ul> 

<p> 

{%  if  previous_week  %} 

Semana  anterior:  {{  previous_week|date:"F  Y" }} 
{%  endif  %} 

{%  if  previous_week  and  next_week  %}--{%  endif  %} 
{%  if  next_week  %} 

Semana  siguiente:  { next_week|date:"F  Y" }} 
{%  endif  %} 

</p> 


En  este  ejemplo,  mostramos  la  salida  de  el  numero  de  semanas.  El  valor 
predeterminado  para  week_format  en  la  vista  WeekArchiveView  usa  '%U'  el  cual  esta 
basado  en  el  sistema  de  semanas  manejado  en  los  Estados  Unidos,  cuyo  inicio  de 
semana  es  el  domingo.  El  formato  ISO  usa  el  formato  de  semanas  '%W',  en  este 
formato  la  semana  comienza  el  lunes.  El  formato  '%W'  es  el  mismo  en  ambas 
funciones:  strftimeO  y en  el  filtro  date. 

Sin  embargo  el  filtro  date  del  el  sistema  de  plantillas  no  tiene  un  equivalente,  para 
la  salida  en  el  formato  que  soporta  el  sistema  de  semanas  US.  El  filtro  date  '%U\ 
muestra  por  salida  el  numero  de  segundos  desde  la  epoca  Unix. 

Argumentos  obligatorios 

• year:  El  ano,  con  cuatro  digitos  (Una  cadena  de  texto). 

• week:  La  semana  del  ano  (Una  cadena  de  texto). 

• queryset:  El  QuerySet  de  los  objetos  archivados. 

• date_field;  El  nombre  del  campo  de  tipo  DateField  o DateTimeField  en  el 
modelo  usado  para  el  QuerySet  que  se  usara  como  fecha  de  referencia. 

Argumentos  opcionales 

• allow_future:  Un  valor  booleano  que  indica  si  deben  incluirse  o no  en  esta 
vista  las  fechas  “en  el  futuro”. 

Nombre  de  la  plantilla 

Si  no  se  ha  especificado  ningun  valor  en  template_name  la  vista  usara  como  plantilla 
<app_label>  / <model_name>_archive_week.html. 

Atributos  de  la  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  definido  en  el  contexto,  la  plantilla 
contendra  los  siguientes  valores: 

• week:  Un  objeto  de  tipo  datetime.date,  cuyo  valor  es  el  primer  dia  de  la 
semana  considerada. 


477  APENDICE  C REFERENCIA  DE  LAS  VISTAS  GENERICAS 


• object_list:  Una  lista  de  objetos  disponibles  para  la  semana  en  cuestion.  El 
nombre  de  esta  variable  depende  del  parametro  template_object_name,  que 
es  'object'  por  defecto.  Si  template_object_name  fuera  'foo',  el  nombre  de  esta 
variable  seria  foojist. 


Archivos  diarios;  DayArchiveView 

Clase:  django. views. generic.dates.BaseDayArchiveView 

Esta  vista  muestra  todos  los  objetos  para  un  dla  determinado.  Los  objetos  con  fechas 
en  el  futuro  muestran  un  error  404,  no  importa  si  existen  objetos  a menos  que  se 
establezca  el  atributo  allowjuture  en  True. 

Ancestros  (MRO) 

• django.views.generic.list.MultipleObjectTemplateResponseMixin 

• django.views.generic.base.TemplateResponseMixin 

• django.views. generic. dates. BaseDayArchiveView 

• dj  ango  .views  .generic . dates . YearMixin 

• dj  ango  .views  .generic . dates . MonthMixin 

• dj  ango  .views  .generic . dates . D ayMixin 

• dj  ango  .views . generic . dates . B aseD  ateListView 

• django.views. generic.list.MultipleObjectMixin 

• dj  ango  .views  .generic . dates . D ateMixin 

• django.views. generic.base.View 


Atributos 

Ademas  del  contexto  ofrecido  por:  MultipleObjectMixin  (a  traves  de 

BaseDateListView),  el  contexto  de  la  plantilla  contendra: 

• day:  Un  objeto  date  que  representa  el  dia  dado. 

• next_day:  Un  objeto  date  object  que  representa  el  dia  siguiente,  de  acuerdo  al 
allow_empty  y allow_future. 

• previous_day:  Un  objeto  date  que  representa  el  dia  anterior,  de  acuerdo  al 
atributo  allow_empty  y allow_future. 

• next_month:  Un  objeto  de  la  clase  date  que  representa  el  primer  dia  de  el 
siguiente  mes,  de  acuerdo  al  atributo  allow_empty  y allow_future. 

• previous_month:  Un  objeto  de  la  clase  date  que  representa  el  primer  dia  del 
mes  anterior,  de  acuerdo  al  atributo  allow_empty  y allow_future. 

Usa  de  forma  predeterminada  _archive_day  como  el  nombre  del  sufijo  de 
plantilla  para  template_name_suffix. 
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Ejemplo: 

Siguiendo  con  nuestro  ejemplo,  anadir  una  vista  diaria  de  objetos  a nuestra 
aplicacion,  no  deberia  ser  mas  complicada  que  las  anteriores. 


biblioteca/views .py 


from  django. views. generic. dates  import  DayArchiveView 
from  biblioteca.models  import  Libro 

class  LibrosDiarios(DayArchiveView): 

queryset  = Libro.  objects.  all() 
date_field  = "fecha_publicacion" 

make_object_list  = 
allow  future  = rue 


biblioteca/biblioteca/urls .py 


from  django. conf.urls  import  url 

from  biblioteca. views  import  LibrosDiarios 

urlpatterns  = [ 

# Ejemplo:  /2012/nov/10/ 

url(r,A(?P<year>[0-9]{4})/(?P<month>[-\w]+)/(?P<day>[0-9]+)/$', 
LibrosDiarios. as_view(),  name="libros-diarios"), 

] 


biblioteca/libro_archive  day . html 


<hl>{{  day  }}</hl> 

<ul> 

{%  for  libros  in  objectjist  %} 

<li>{{  libros. fecha_publicacion|date  'F  j,  Y" }}:  {{ libro. titulo  }}</li> 
{%  endfor  %} 

</ul> 

<p> 

{%  if  previous_day  %} 

Dia  anterior:  previous_day }} 

{%  endif  %} 

{%  if  previous_day  and  next_day  %}--{%  endif  %} 

{%  if  next_day  %} 

Siguiente  dia:  { next_day 
{%  endif  %} 

</p> 


Argumentos  obligatorios 

• year:  El  ano,  con  cuatro  dlgitos  (Una  cadena  de  texto). 

• month:  El  mes,  formateado  de  acuerdo  a lo  indicado  por  el  argumento 
month_format. 

• day:  El  dia,  formateado  de  acuerdo  al  argumento  day_format. 
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• queryset:  El  QuerySet  de  los  objetos  archivados. 

• date_field;  El  nombre  del  campo  de  tipo  DateField  o DateTimeField  en  el 
modelo  usado  para  el  QuerySet  que  se  usara  como  fecha  de  referenda. 

Argumentos  opcionales 

• month_format:  Elna  cadena  de  texto  que  determina  el  formato  que  debe  usar 
el  parametro  month.  Elay  una  explicacion  mas  detallada  en  la  seccion  de 
“Arch i vos  mensuales”,  incluida  anteriormente. 

• day_format:  Equivalente  a month_format,  pero  para  el  dia.  Su  valor  por 
defecto  es  "%d"  (que  es  el  dia  del  mes  como  numero  decimal  y relleno  con 
ceros  de  ser  necesario;  01-31). 

• allow_future:  Un  valor  booleano  que  indica  si  deben  incluirse  o no  en  esta 
vista  las  fechas  “en  el  futuro”. 

Nombre  de  la  plantilla 

Si  no  se  ha  especificado  ningun  valor  en  template_name  la  vista  usara  como  plantilla 

<app_label>/<model_name>_archive_day.html. 

Atributos  de  la  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  delinido  en  el  contexto,  la  plantilla  tendra 

los  siguientes  valores: 

• day:  Un  objeto  de  tipo  datetime. date  cuyo  valor  es  el  del  dia  en  cuestion. 

• next_day:  Un  objeto  de  tipo  datetime.date  que  representa  el  siguiente  dia.  Si 
cae  en  el  futuro,  valdra  None. 

• previous_day:  Un  objeto  de  tipo  datetime.date  que  representa  el  dia  anterior. 
A1  contrario  que  next_day,  su  valor  nunca  sera  None. 

• object_list:  Una  lista  de  objetos  disponibles  para  el  dia  en  cuestion.  El 
nombre  de  esta  variable  depende  del  parametro  template_object_name,  que 
es  object  por  defecto.  Si  template_object_name  fuera  foo,  el  nombre  de  esta 
variable  serfa  foojist. 


Archivo  para  hoy:  Today ArchiveView 
Clase:  django. views. generic.dates.BaseTodayArchiveView 

Esta  vista  muestra  todos  los  objetos  cuya  fecha  de  referencia  sea  hoy.  Es  parecida  a 
django.views.  generic,  dates.  DayArchiveView,  excepto  que  no  se  utilizan  los 
argumentos  year. /month /day,  ya  que  esos  datos  se  obtendran  de  la  fecha  actual. 

Ancestros  (MRO) 

• django.views. generic.list.MultipleObjectTemplateResponseMixin 

• django.views. generic.base.TemplateResponseMixin 
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• dj  ango  .views  .generic . dates . BaseT  o dayArchiveVie  w 

• django.views. generic. dates. BaseDayArchiveView 

• dj  ango  .views  .generic . dates . YearMixin 

• dj  ango  .views  .generic . dates . M onthMixin 

• dj  ango  .views  .generic . dates . D ayMixin 

• dj  ango  .views . generic . dates . B aseD  ateListView 

• django.views. generic.list.MultipleObjectMixin 

• dj  ango  .views  .generic . dates . D ateMixin 

• django.views. generic.base.View 

Usa  de  forma  predeterminada  _archive_today  como  el  nombre  del  sufijo  de 
plantilla  para  template_name_suffix. 

Ejemplo: 

Siguiendo  con  ejemplo  anterior,  podemos  anadir  una  vista  para  mostrar  los  objetos 
del  dia  de  hoy  de  la  siguiente  forma. 


biblioteca/views .py 


from  django.views. generic. dates  import  TodayArchiveView 
from  biblioteca.models  import  Libro 

class  LibrosPublicadosHoy(TodayArchiveView): 

queryset  = Libro. objects. all() 
date_field  = "fecha_publicacion" 
make_object_list  = rue 
allow  future  = 'rue 


biblioteca/urls .py 


from  django.conf.urls  import  url 

from  myapp. views  import  LibrosPublicadosHoy 

urlpatterns  = [ 

url(r'Ahoy/$',  LibrosPublicadosHoy. as_view(),  name-'libros-publicados-hoy"), 

] 


^Donde  esta  la  plantilla  para  todayarchiveview? 


Esta  vista  usa  de  forma  predeterminada  la  misma  plantilla  que  la  clase 
DayAr  chive  View,  como  en  el  ejemplo  anterior.  Si  necesitas  una  plantilla  diferente, 
establece  un  atributo  template_name  para  utilizar  el  nombre  de  la  nueva  plantilla. 


Paginas  de  detalle  basadas  en  fecha:  DateDetailView 
Clase:  django. views. generic.dates.BaseDateDetailView 

Esta  vista  se  usa  para  representar  un  objeto  individual.  Los  objetos  con  fechas  en  el 
futuro  muestran  un  error  404,  no  importa  si  existen  los  objetos  a menos  que  se 
establezca  el  atributo  allow_future  en  True. 
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Ancestros  (MRO) 

• django.views. generic. detail.SingleObjectTemplateResponseMixin 

• django.views. generic.base.TemplateResponseMixin 

• django.views. generic. dates. BaseDateDetailView 

• dj  ango  .views  .generic . dates . YearMixin 

• dj  ango  .views  .generic . dates . MonthMixin 

• dj  ango  .views  .generic . dates . D ayMixin 

• dj  ango  .views  .generic . dates . D ateMixin 

• dj  ango  .views . generic . detail.  BaseD  etailVie  w 

• dj  ango  .views  .generic . detail.  SingleOb  jectMixin 

• django.views. generic.base.View 

Atributos 


Incluye  el  unico  objeto  asociado  al  modelo  especificado  en  DateDetailView. 

Usa  de  forma  predeterminada  _detail  como  el  nombre  del  sufijo  de  plantilla  para 
template_name_suffix. 

Esta  vista  tiene  una  URL  distinta  de  la  vista  DetailView;  mientras  que  la  ultima  usa 
una  URL  como,  por  ejemplo,  /entradas/<slug>/,  esta  usa  una  URL  en  la  forma 
/ entradas  / 2006  / aug/  27  / <slug>  / . 


Nota:  Si  estas  usando  paginas  de  detalle  basadas  en  fechas  con  slugs  e n la  URL,  lo 
mas  probable  es  que  quieras  usar  la  opcion  unique_for_date  en  el  campo  slug,  de 
forma  que  se  garantice  que  los  slugs  nunca  se  duplican  para  una  misma  fecha. 


Ejemplo: 

Esta  vista  tiene  una  (pequena)  diferencia  con  las  demas  vistas  basadas  en  fechas  que 
hemos  visto  anteriormente,  y es  que  necesita  que  le  especifiquemos  de  forma 
inequivoca  el  objeto  en  cuestion;  esto  lo  podemos  hacer  con  el  identificador  del 
objeto  pko  con  un  campo  de  tipo  slug. 

Como  el  objeto  que  estamos  usando  en  el  ejemplo  no  tiene  ningun  campo  de  tipo 
slug,  usaremos  el  identificador  para  la  URL.  Normalmente  se  considera  una  buena 
practica  usar  un  campo  slug,  pero  no  lo  haremos  en  aras  de  simplificar  el  ejemplo. 


biblioteca/urls .py 


from  django.conf.urls  import  url 

from  django.views. generic. dates  import  DateDetailView 

from  biblioteca.models  import  Libro 
urlpatterns  = [ 

url(r'A(?P<year>[0-9]+)/(?P<month>[-\w]+)/(?P<day>[0-9]+)/(?P<pk>[0-9]+)/$', 
DateDetailView.as_view(model=Libro,  date_field="fecha_publicacion"), 
name="libros-detalle-por-fecha"), 


] 
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biblioteca/libro  detail.html 


<hl>{{  object. titulo  }}</hl> 


Argumentos  obligatorios 

• year:  El  ano,  con  cuatro  digitos  (Una  cadena  de  texto). 

• month:  El  mes,  formateado  de  acuerdo  a lo  indicado  por  el  argumento 
month_format 

• day:  El  dia,  formateado  de  acuerdo  al  argumento  day_format. 

• queryset:  El  QuerySet  que  contiene  el  objeto. 

• date_field:  El  nombre  del  campo  de  tipo  DateField  o DateTimeField  en  el 
modelo  usado  para  el  QuerySet  que  se  usara  como  fecha  de  referenda. 

Y tambien  habra  que  especiflcar,  o bien  un: 

• object_id:  El  valor  de  la  clave  primaria  del  objeto,  o bien  un:  slug:  El  slug  del 
objeto.  Si  se  utiliza  este  argumento,  es  obligatorio  especiflcar  un  valor  para  el 
argumento  slug_field  (que  describiremos  en  la  siguiente  section). 


Argumentos  opcionales 

• allow_future:  Un  valor  booleano  que  indica  si  deben  incluirse  o no  en  esta 
vista  las  fechas  “en  el  futuro”. 

• day_format:  Equivalente  a month_format,  pero  para  el  dia.  Su  valor  por 
defecto  es  "%d"  (que  es  el  dia  del  mes  como  numero  decimal  y relleno  con 
ceros  de  ser  necesario;  01-31). 

• month_format:  Una  cadena  de  texto  que  determina  el  formato  que  debe  usar 
el  parametro  month.  Hay  una  explication  mas  detallada  en  la  section  de 
“Archivos  mensuales”,  incluida  anteriormente. 

• slug_field:  El  nombre  del  atributo  que  almacena  el  valor  del  slug*.  Es 
obligatorio  incluirlo  si  se  ha  usado  el  argumento  slug,  y no  debe  aparecer  si  se 
ha  especiflcado  el  argumento  object_id. 

• template_name_fl,e7r/:  El  nombre  de  un  atributo  del  objeto  cuyo  valor  se 
usara  como  el  nombre  de  la  plantilla  a utilizar.  De  esta  forma,  puedes 
almacenar  en  tu  objeto  la  plantilla  a usar. 

Nombre  de  la  plantilla 

Si  no  se  ha  especiflcado  ningun  valor  en  template_name  la  vista  usara  como  plantilla 
<app_label>/<model_name>_detail.html. 

Atributos  de  la  plantilla 

Ademas  de  los  valores  que  se  puedan  haber  deflnido  en  el  contexto,  la  plantilla 
contendra  los  siguientes  valores: 


483  APENDICE  C REFERENCIA  DE  LAS  VISTAS  GENERICAS 


• object;  El  objeto  en  si  mismo,  el  nombre  de  esta  variable  depende  del 
parametro  template_object_name,  que  es  object  por  defecto.  Si 
template_object_name  fuera  foo,  el  nombre  de  esta  variable  seria  foo. 


Todas  las  vistas  genericas  basadas  en  clases  listadas  anteriormente,  corresponden 
y heredan  de  la  vista  Base,  unicamente  difieren  de  ella  en  que  no  incluyen  la  clase 
MultipleObjectTemplateResponseMixin  (para  las  vistas  de  archivos)  o 
SingleObjectTemplateResponseMixin  (para  la  clase  DateDetailView). 


APENDICE  D 


Variables  de  configuracion 


El  archivo  de  configuracion  setting.py  contiene  toda  la  configuracion  de  tu 

instalacion  Django.  Este  apendice  explica  como  funcionan  la  mayoria  de  las  variables 
de  configuracion  y que  variables  de  configuracion  estan  disponibles. 


Nota:  A medida  que  Django  crece,  es  ocasionalmente  necesario  agregar,  quitar  o 
cambiar  algunas  variables  de  configuracion.  Debes  siempre  buscar  la  information 
mas  reciente  en  la  documentation  oficial  en  linea,  que  se  encuentra  disponible  en  el 
sitio  del  proyecto  ® http://www.djangoproject.com/documentation/. 


Que  es  un  archivo  de  configuracion 

Un  archivo  de  configuracion  es  solo  un  modulo  Python  con  variables  a nivel  de 
modulo. 

Un  par  de  ejemplos  de  variables  de  configuracion: 

DEBUG  = False 

DEFAULT_FROM_EMAIL  = ’webmaster@example.com’ 

Debido  a que  un  archivo  de  configuracion  es  un  modulo  Python,  las  siguientes 
afirmaciones  son  ciertas: 

• Debe  ser  codigo  Python  valido;  no  se  permiten  los  errores  de  sintaxis. 

• El  mismo  puede  asignar  valores  a las  variables  dinamicamente  usando 
sintaxis  normal  de  Python,  por  ejemplo: 

MI_CONFIGURACION  = [str(i)  for  i in  range(30)] 

• El  mismo  puede  importar  valores  desde  otros  archivos  de  configuracion. 


Valores  predeterminados 

No  es  necesario  que  un  archivo  de  configuracion  de  Django  defina  una  variable  de 
configuracion  si  es  que  no  es  necesario.  Cada  variable  de  configuracion  tiene  un  valor 
por  omision  sensato.  Dichos  valores  por  omision  residen  en  el  archivo 
django/conf/global_settings.py. 

Este  es  el  algoritmo  que  usa  Django  cuando  compila  los  valores  de  configuracion: 
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1 . Carga  las  variables  de  configuracion  desde  global_settings. 

2.  Carga  las  variables  de  configuracion  desde  el  archivo  de  configuracion 
especificado,  reemplazando  de  ser  necesario  los  valores  globales  previos. 

Nota  que  un  archivo  de  configuracion  no  debe  importar  desde  globaLsettings,  ya 
que  eso  seria  redundante. 

^Como  saber  cuales  variables  de  configuracion  has  cambiado? 

Existe  una  manera  facil  de  ver  cuales  de  tus  variables  de  configuracion  difieren  del 
valor  por  omision.  El  comando  manage.py  diffsettings  visualiza  las  diferencias  entre 
el  archivo  de  configuracion  actual  y los  valores  por  omision  de  Django, 
manage.py  es  descrito  con  mas  detalle  en  el  Apendice  G. 

Usando  variables  de  configuracion  en  codigo  Python 

En  tus  aplicaciones  Django,  usa  variables  de  configuracion  importando  el  objeto 
django.conf. settings,  por  ejemplo: 

from  django.conf  import  settings 

if  settings. DEBUG: 

# Haz  algo 

Nota  que  django.conf.settings  no  es  un  modulo  - es  un  objeto.  De  manera  que  no  es 
posible  importar  variables  de  configuracion  individualmente. 

from  django.conf.settings  import  DEBUG  # No  trabaja. 

Ten  en  cuenta  tambien  que  tu  codigo  no  debe  importar  ni  desde  global_settings  ni 
desde  tu  propio  archivo  de  configuracion.  django.conf.settings  provee  abstraction 
para  los  conceptos  de  variables  de  configuracion  por  omision  y variables  de 
configuracion  especificas  de  un  sitio;  presenta  una  unica  interfaz.  Tambien  desacopla 
el  codigo  que  usa  variables  de  configuracion  de  la  ubicacion  de  dicha  configuracion. 

Modificando  variables  de  configuracion  en  tiempo  de  ejecucion 

No  debes  alterar  variables  de  configuracion  en  tiempo  de  ejecucion.  Por  ejemplo,  no 
hagas  esto  en  una  vista: 

from  django.conf  import  settings 

settings. DEBUG  = True  # jNo  hagas  esto! 

El  unico  lugar  en  el  que  debes  asignar  valores  a settings  es  en  un  archivo  de 
configuracion. 

Seguridad 

Debido  que  un  archivo  de  configuracion  contiene  information  importante,  tal  como 
la  contrasena  de  la  base  de  datos,  debes  hacer  lo  que  este  e tus  manos  para  limitar  el 
acceso  al  mismo.  Por  ejemplo,  cambia  los  permisos  de  acceso  en  el  sistema  de 
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archivos  de  manera  que  solo  tu  y el  usuario  de  tu  servidor  Web  puedan  leerlo.  Esto  es 
especialmente  importante  en  un  entorno  de  alojamiento  compartido. 

Creando  tus  propias  variables  de  configuracion: 
DJANGO_SETTINGS_MODULE 

No  existe  nada  que  impida  que  crees  tus  propias  variables  de  configuracion,  para  tus 
propias  aplicaciones  Django.  Solo  sigue  las  siguientes  convenciones: 

Usa  nombres  de  variables  en  mayusculas. 

Para  configuraciones  que  sean  secuencias,  usa  tuplas  en  lugar  de  listas.  Las 
variables  de  configuracion  deben  ser  consideradas  inmutables  y no  deben  ser 
modificadas  una  vez  que  se  las  ha  definido.  El  usar  tuplas  refleja  esa  semantica. 

No  reinventes  una  variable  de  configuracion  que  ya  existe. 

Indicando  la  configuracion:  DJANGO_SETTINGS_MODULE 

Cuando  usas  Django  tienes  que  indicarle  que  configuracion  estas  usando.  Haz  esto 
mediante  el  uso  de  de  la  variable  de  entorno  DJANGO_SETTINGS_MODULE. 

El  valor  de  DJANGO_SETTINGS_MODULE  debe  respetar  la  sintaxis  de  rutas  de 
Python  (por  ej.  mysite.settings.  Notar  que  el  modulo  de  configuracion  debe  ser 
encontrarse  en  la  ruta  de  busqueda  para  las  importaciones  de  Python 
(PYTHONPATH). 


Nota:  Puedes  encontrar  una  buena  guia  acerca  de  PYTHONPATH  en 
http:  / / diveintopython.org/getting_to_know_python/everything_is_an_object.html. 


La  utilidad  django-admin.py 

Cuando  usas  django-admin.py  (ver  Apendice  F),  puedes  ya  sea  fijar  el  valor  de  la 
variable  de  entorno  una  vez  o especificar  explicitamente  el  modulo  de  configuracion 
cada  vez  que  ejecutes  la  utilidad. 

Este  es  un  ejemplo  usando  el  shell  Bash  de  Unix: 

export  DJANGO_SETTINGS_MODULE=mysite. settings 
django-admin.py  runserver 

Este  es  otro  ejemplo,  esta  vez  usando  el  shell  de  Windows: 

set  DJANGO_SETTINGS_MODULE=mysite. settings 
django-admin.py  runserver 

Usa  el  argumento  de  linea  de  comandos  --settings  para  especificar  el  modulo  de 
configuracion  en  forma  manual: 

django-admin.py  runserver  -settings=mysite. settings 

La  utilidad  manage.py  creada  por  el  comando  startproject  como  parte  del 
esqueleto  del  proyecto  asigna  un  valor  a DJANGO_SETTINGS_MODULE  en  forma 
automatical  revisa  el  Apendice  G si  deseas  conocer  mas  sobre  manage.py. 
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En  el  servidor  (mod_wsgi) 

En  tu  entorno  del  servidor  activo,  necesitaras  indicarle  a WSGI  application  que 
archivo  de  configuracion  debe  usar.  Haz  eso  con  os. environ. 

import  os 

os.environ[’DJANGO_SETTINGS_MODULE’]  = ’misitio.  settings’ 

Usando  variables  de  configuracion  sin  usar 
DJANGO_SETTINGS_MODULE 


Es  algunos  casos,  querras  saltearte  la  variable  de  entorno 
D JAN  GO_SETTINGS_MODULE. 

Por  ejemplo,  si  estas  usando  el  sistema  de  plantillas  en  forma  aislada,  muy 
probablemente  no  desearas  tener  que  preparar  una  variable  de  entorno  que  apunte  a 
un  modulo  de  configuracion. 

En  esos  casos,  puedes  fijar  los  valores  de  las  variables  de  configuracion  de  Django 
manualmente.  Elaz  esto  llamando  a django.conf.settings. configure!).  Este  es  un 
ejemplo: 

from  django.conf  import  settings 

settings. configure(DEBUG=True,  TEMPLATE_DEBUG=True, 
TEMPLATE_DIRS=(7home/web-apps/myapp’,  ’/home/web-apps/base’)) 

Pasale  a configure!)  tantos  argumentos  de  palabra  clave  como  desees,  con  cada 
argumento  representando  una  variable  de  configuracion  y su  valor.  Cada  nombre  de 
argumento  debe  estar  escrito  totalmente  en  mayusculas,  con  el  mismo  nombre  que 
la  variable  de  configuracion  que  ya  se  describieron.  Si  una  variable  de  configuracion 
no  es  pasada  a configure!)  y es  necesario  luego,  Django  usara  el  valor  por  omision 
respectivo. 

El  configurar  Django  de  esta  manera  es  en  general  necesario  - y,  en  efecto, 
recomendado,  cuando  usas  una  parte  del  framework  dentro  de  una  aplicacion  mas 
grande. 

En  consecuencia,  cuando  es  configurado  via  settings. configured!),  Django  no  hara 
modification  alguna  a las  variables  de  entorno  del  proceso  (revisa  la  explication 
acerca  de  TIME_ZONE  mas  adelante  en  este  apendice  para  conocer  por  que  habria 
de  ocurrir  esto).  Asumimos  que  en  esos  casos  ya  tienes  completo  control  de  tu 
entorno. 

Variables  de  configuracion  personalizados 

Si  te  gustaria  que  los  valores  por  omision  provinieran  desde  otra  ubicacion  diferente 
a django.conf.globaLsettings,  puedes  pasarle  un  modulo  o una  clase  que  provea  las 
variables  de  configuracion  por  omision  como  el  argumento  default_settings  (o  como 
el  primer  argumento  posicional)  en  la  llamada  a configure!). 

En  este  ejemplo,  las  variables  de  configuracion  por  omision  se  toman  desde 
myapp- defaults,  y se  fija  el  valor  de  DEBUG  en  True,  independientemente  de  su  valor 
en  myapp_defaults: 

from  django.conf  import  settings 
from  myapp  import  myapp_defaults 
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settings. configure(default_settings=myapp_defaults,  DEBUG=True) 

El  siguiente  ejemplo,  que  usa  myapp_defaults  como  un  argumento  positional,  es 
equivalente: 

settings. configure(myapp_defaults,  DEBUG  = True) 

Normalmente,  no  necesitaras  sobrescribir  los  valores  por  omision  de  esta  manera. 
Los  valores  por  omision  provistos  por  Django  son  suficientemente  sensatos  como 
para  que  puedas  usarlos.  Ten  en  cuenta  que  si  pasas  un  nuevo  valor  por  omision,  este 
reemplaza  completamente  los  valores  de  Django,  asi  que  debes  especificar  un  valor 
para  cada  variable  de  configuracion  posible  que  pudiera  ser  usado  en  el  codigo  que 
estas  importando.  Examina  django.conf.settings.global_settings  para  ver  la  lista 
completa. 

Usa  configure  ()  o DJANGO_SETTINGS_MODULE 

Si  no  estas  fijando  la  variable  de  entorno  DJANGO_SETTINGS_MODULE,  debes 
llamar  a configure!)  en  algun  punto  antes  de  usar  cualquier  codigo  que  lea  las 
variables  de  configuracion. 

Si  no  fijas  DJANGO_SETTINGS_MODULE  y no  llamas  a configure!),  Django  lanzara 
una  exception  EnvironmentError  la  primera  vez  que  se  accede  a una  variable  de 
configuracion. 

Si  fijas  el  valor  de  DJANGO_SETTINGS_MODULE,  luego  accedes  a los  valores  de 
las  variables  de  configuracion  de  alguna  manera,  y entonces  llamas  a configure!), 
Django  lanzara  un  EnvironmentError  indicando  que  la  configuracion  ya  ha  sido 
preparada. 

Tambien  es  un  error  el  llamar  a configure!)  mas  de  una  vez,  o llamar  a configure 
luego  de  que  ya  se  ha  accedido  a alguna  variable  de  configuracion. 

En  resumen:  Usa  exactamente  una  vez  ya  sea  configure!)  o 

DJANGO_SETTINGS_MODULE.  No  ambos,  y no  ninguno. 


Variables  de  configuracion  disponibles 


Las  siguientes  secciones  consisten  de  una  lista  completa  de  todas  las  variables  de 
configuracion  en  orden  alfabetico,  y sus  valores  por  omision. 


Nota:  Ten  cuidado  al  sobrescribir  alguna  configuracion,  especialmente  cuando  el 
valor  predeterminado  no  esta  vacio,  es  un  diccionario  o una  tupla,  tal  como 
MIDDLEWARE_CLASSES  y TEMPLATE_CONTEXT_PROCESSORS.  Asegurate  que  los 
componentes  requeridos  esten  disponibles  para  usar  esta  caracterfstica  de  Django. 


ABSOLUTE_URL_OVERRIDES 

Valor  por  omision:  {}  (Diccionario  vacio) 

Un  diccionario  enlazando  cadenas  app_label.model_name  a funciones  que  toman  un 
objeto  modelo  y retornan  su  URL.  Esta  es  una  forma  de  sobrescribir  metodos 
get_absolute_url()  en  cada  instalacion.  Un  ejemplo: 
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ABSOLUTE_URL_OVERRIDES  = { 

’blogs. weblog’:  lambda  o:  "/blogs/%s/"  % o.slug, 

’news. story’:  lambda  o:  7stories/%s/%s/"  % (o.pub_year,  o.slug), 

} 


Nota  que  el  nombre  del  modelo  usado  en  esta  variable  de  configuracion  debe  estar 
escrito  totalmente  en  mayusculas,  con  independencia  de  la  combination  de 
mayusculas  y minusculas  del  nombre  real  de  la  clase  del  modelo. 

ABSOLUTE_URL_OVERRIDES  no  funciona  en  modelos  que  no  tienen  declarado 
un  metodo  get_absolute_url(). 

ADMINS 

Valor  por  omision:  ()  (Tupla  vacia) 

Una  tupla  que  enumera  las  personas  que  recibiran  notificaciones  de  errores  en  el 
codigo.  Cuando  DEBUG=False  y una  vista  laza  una  exception,  Django  enviara  a esta 
gente  un  e-mail  con  la  information  completa  de  la  information.  Cada  miembro  de  la 
tupla  debe  ser  una  tupla  de  (Nombre  completo,  direction  de  e-mail),  por  ejemplo: 

((’John’,  ’john@example.com’),  (’Mary’,  ’mary@example.com’)) 

Observa  que  Django  el  enviara  e-mail  a todas  estas  personas  cada  vez  que  ocurra 
un  error. 

ALLOWED_HOSTS 
Valor  por  omision:  []  (Lista  vacia) 

Una  lista  de  cadenas  que  representa  el  nombre  del  host/dominio  que  usa  el  sitio  de 
Django.  Se  trata  de  una  medida  de  seguridad,  que  impide  que  un  atacante  puede 
envenenar  la  cache  y resetear  contrasenas  enviando  emails  con  links  a sitios 
maliciosos,  enviando  peticiones  HTTP  con  cabeceras  falsas  Host,  lo  cual  es  posible 
incluso  bajo  muchas  configuraciones  aparentemente-seguras  del  servidor  web. 

ALLOWED_INCLUDE_ROOTS 

Valor  por  omision:  ()  (Tupla  vacia) 

Una  tupla  de  cadenas  que  representan  prefijos  permitidos  para  la  etiqueta  de 
plantillas  {%  ssi  %}.  Se  trata  de  una  medida  de  seguridad,  que  impide  que  los  autores 
de  plantillas  puedan  acceder  a archivos  a los  que  no  deberian  acceder. 

Por  ejemplo,  si  ALLOWED_INCLUDE_ROOTS  es  ('/home/html',  ’/var/www’) 
entonces  {%  ssi  /home/html/foo.txt  %}  funcionaria  pero  {%  ssi  /etc/passwd  %}  no. 


APPEND_SLASH 
Valor  por  omision:  True 

Esta  variable  de  configuracion  indica  si  debe  anexarse  barras  al  final  de  las  URLs.  Se 
usa  solamente  si  esta  instalado  el  CommonMiddleware  (ver  capitulo  17). 
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CACHES 

Valor  por  omision: 

CACHES{ 

'default':  { 

'BACKEND':  'django. core. cache. backends. locmem.LocMemCache', 

} 

} 

Un  diccionario  que  contiene  la  configuracion  para  todas  las  caches  que  se  usaran 
con  Django.  Es  un  diccionario  jerarquizado  cuyos  contenidos  asocian  en  forma  de 
alias  un  diccionario  que  contiene  las  opciones  para  usar  la  cache  de  forma  individual. 

La  configuracion  de  CACHES  debe  configurar  el  valor  predeterminado  default 
cache;  y cualquier  numero  adicional  de  caches  debe  ser  especiflcado.  Si  estas  usando 
algun  tipo  de  backend  u otra  cache  en  memoria  o necesitas  definir  multiples  caches, 
necesitas  definir  otras  opciones.  Las  siguientes  opciones  de  cache  estan  disponibles: 

BACKEND 

Valor  por  omision: " (Una  cadena  vacia) 

El  backend  para  usar  como  cache.  Los  backends  incorporados  en  la  cache  son: 

'django. core. cache,  backends. db.DatabaseCache' 

'django. core. cache,  backends. dummy.  DummyCache' 

'django. core. cache,  backends. filebased.FileBasedCache' 

'django. core. cache,  backends. locmem.LocMemCache' 

'django. core. cache,  backends. memcached.MemcachedCache' 

'django.  core,  cache,  backends.  memcached.PyLibMCCache' 

Puedes  usar  algun  otro  tipo  de  almacenamiento  para  la  cache  o backend 
configurando  BACKEND  con  la  ruta  completa  a la  clase  backend  que  estes  usando. 
Por  ejemplo  mipaquete.backends.whatever.WhateverCache 

KEY_FUNCTION 

Una  cadena  que  contiene  la  ruta  a la  funcion  (o  cualquier  llamable)  que  define  la 
forma  en  que  se  compone  el  prefijo,  version  y key  en  la  clave  de  la  cache  final.  El  valor 
predeterminado  es  equivalente  a la  funcion: 

def  make_key(key,  key_prefix,  version): 
return  ,join([key_prefix,  str(version),  key]) 

Puedes  usar  cualquier  funcion  clave  que  quieras,  siempre  que  tenga  los  mismos 
argumentos. 


KEY_PREFIX 

Valor  por  omision: " (Cadena  Vacia) 

Una  cadena  que  estara  automaticamente  incluida  ( agregada  por  omision)  en  todas  la 
claves  de  la  cache  usadas  por  el  servidor. 
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LOCATION 

Valor  por  omision: " (Cadena  Vacia) 

La  localization  de  la  cache  a utilizar.  Esta  puede  ser  el  directorio  para  usar  un  archivo 
como  sistema  de  cache,  un  host  o un  puerto  para  el  servidor  de  memcache,  o 
simplemente  un  nombre  para  identificar  la  memoria  local  que  se  este  usando,  por 
ejemplo: 

CACHES  = { 

'default':  { 

'BACKEND':  'django. core. cache. backends. filebased.FileBasedCache', 
'LOCATION':  7var/tmp/django_cache', 

} 

} 

OPTIONS 

Valor  por  omision:  None 

Parametros  extra  para  pasar  a la  cache.  Los  parametros  disponibles  varian 
dependiendo  del  tipo  de  backend  usado  para  la  cache. 

TIMEOUT 

Valor  por  omision:  300 

El  numero  de  segundos  antes  de  que  una  entrada  en  la  cache  expire.  Si  el  valor  de  la 
configuracion  es  None,  la  entrada  en  la  cache  no  expira. 

VERSION 

Valor  por  omision:  1 

El  valor  predeterminado  para  el  numero  de  version,  generado  por  el  servidor. 

CACHE_MIDDLEWARE_ALIAS 
Valor  por  omision:  default 

La  conexion  a la  cache  a usar  por  el  middleware  de  cache. 

CACHE_MIDDLEWARE_KEY_PREFIX 
Valor  por  omision: " (Cadena  vacia) 

El  prefijo  de  las  claves  de  cache  que  debe  usar  el  middleware  de  cache  (ver  capitulo 
17). 
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CACHE_MIDDLEWARE_SECONDS 
Valor  por  omision:  600 

El  valor  predeterminado  para  el  numero  de  segundos  que  se  mantendra  en  cache  una 
pagina,  cuando  se  usen  el  middleware  de  cacheo  o el  decorador  cache_page(). 

CSRF_COOKIE_AGE 

Valor  por  omision:  31449600  (1  ano,  en  segundos) 

La  edad  de  las  cookies  CSRF,  en  segundos. 

La  razon  para  conligurar  el  tiempo  de  vida  y expiration  de  las  cookies,  es  para 
evitar  problemas  en  el  caso  de  que  se  cierre  el  navegador  de  un  usuario  o una  pagina 
de  marcadores  y se  cargue  la  pagina  desde  la  cache  del  navegador.  Sin  cookies 
persistentes,  los  formularios  para  subir  datos  fallaran. 

Algunos  navegadores  (especialmente  Internet  Explorer)  pueden  rechazar  el  uso  de 
cookies  persistentes  o pueden  tener  indices  de  cookies  corrompidos  en  el  disco,  por 
consiguiente  causan  que  la  comprobacion  de  proteccion  CSRF  falle  (a  veces 
intermitentemente).  Cambia  esta  configuracion  a None  para  usar  cookies  basadas  en 
sesion  CSRF,  que  guardan  en  la  memoria  las  cookies,  en  vez  de  usar  el 
almacenamiento  persistente. 

CSRF_COOKIE_DOMAIN 

Valor  por  omision:  None 

El  dominio  para  usar  cuando  se  usa  la  configuracion  para  cookie  CSRF.  Esto  puede 
ser  util  para  facilmente  permitir  peticiones  de  dominios  cruzados  para  excluirlas 
normalmente  de  la  proteccion  de  falsification  de  peticion  de  sitio.  Esta  puede  ser  una 
cadena  tal  como  ".example.com",  para  permitir  que  una  peticion  POST  de  un 
formulario  en  un  subdominio  sea  validada  por  una  vista  que  es  servida  por  otro 
subdominio. 

Nota  que  la  presencia  de  esta  configuracion  no  implica  que  la  proteccion  Django 
CSRF  sea  segura  de  ataques  en  subdominios  cruzados  de  forma  predeterminada. 

CSRF_COOKIE_HTTPONLY 

Valor  por  omision:  False 

Usado  solo  si  utilizas  la  bandera  HttpOnly  en  la  cookie  de  CSRF.  Si  se  fija  en  True, 
Java  Script  del  lado-cliente  no  podra  acceder  a las  cookie  CSRF. 

Esto  puede  ayudar  a prevenir  Java  Script  malicioso  que  pueda  sobrepasar  la 
proteccion  CSRF.  Si  permites  y necesitas  enviar  valores  al  CSRF  con  peticiones  Ajax, 
Java  Script  necesitara  empujar  el  valor  de  un  token  CSRF  oculto  en  los  formularios  de 
entrada  en  la  pagina,  en  lugar  de  las  cookie. 

CSRF_COOKIE_NAME 

Valor  por  omision:  'csrftoken' 

El  nombre  de  la  cookie  para  usar  el  token  CSRF  de  autentificacion.  Este  puede  ser  el 
que  quieras. 
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CSRF_COOKIE_PATH 
Valor  por  omision: '/' 

La  ruta  establecida  en  la  cookie  CSRF.  Este  deberfa  corresponder  a la  URL  de  la  ruta 
de  instalacion  Django  o puede  ser  una  ruta  padre  de  esa  ruta. 

Esto  es  util  si  tienes  multiples  instancias  de  Django  ejecutandose  bajo  el  mismo 
nombre  de  dominio  o 'hostname.  Puedes  usara  diferentes  rutas  para  las  cookies  y 
cada  caso  considerara  solamente  su  propia  cookies  CSRF. 

CSRF_COOKIE_SECURE 

Valor  por  omision:  False 

Se  asegura  que  la  cookie  sea  marcada  como  segura.  Si  esta  establecido  en  True,  La 
cookie  sera  marcada  como  “segura,”  lo  cual  quiere  decir  que  los  navegadores  pueden 
asegurar  que  la  cookie  es  solo  enviada  bajo  una  conexion  HTTPS. 

CSRF_FAILURE_VIEW 

Valor  por  omision:  'django.views.csrf.csrfjailure' 

La  ruta  a la  funcion  vista,  para  usar  cuando  una  peticion  entrante  sea  rechazada  por 
la  protection  CSRF.  La  funcion  debe  tener  esta  firma: 

def  csrf_failure(request,  reason-'") 

Donde  reason  es  un  mensaje  corto  (previsto  para  los  desarrolladores,  no  para  los 
usuarios  finales)  indica  la  razon  por  la  que  la  peticion  fue  rechazada. 

DATABASES 

Valor  por  omision:  (Un  diccionario  vacio) 

Un  diccionario  que  contiene  las  configuraciones  para  todas  las  bases  de  datos  usadas 
con  Django.  Es  un  diccionario  jerarquizado  cuyo  contenido  mapea  alias  de  la  base  de 
datos  a un  diccionario,  conteniendo  las  opciones  para  una  base  de  datos  individual. 

La  configuracion  DATABASES  debe  permitir  configurar  una  base  de  datos  por 
default  y cualquier  numero  de  bases  de  datos  adicionales  que  puedan  especificarse. 

La  configuracion  mas  simple  posible  es  para  una  simple  base  de  datos  usando 
SQLite.  Esta  se  puede  configurar  de  la  siguiente  forma: 

DATABASES  = { 

’default’:  { 

’ENGINE’:  ’django.db. backends. sqlite3', 

’NAME’:  ’datos. db’, 

} 

} 


Cuando  se  conecta  a otras  bases  de  datos,  tal  como  MySQL,  Oracle  o PostgreSQL  es 
necesario  agregar  los  parametros  de  conexion  que  requiera. 

Por  ejemplo  para  configurar  PostgreSQL: 
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DATABASES  = { 

’default’:  { 

’ENGINE’:  ’django.db. backends. postgresql_psycopg2’, 
’NAME’:  ’datos.db’, 

’USER’:  ’nombreusuario’, 

’PASSWORD’:  ’contrasena’, 

’HOST’:  ’127.0.0.1’, 

’PORT’:  ’5432’, 

} 

} 


Las  siguientes  opciones  internas  disponibles  pueden  ser  requeridas  para 
configurar  conexiones  mas  complejas  usando  la  variable  DATABASES. 


ATOMIC_REQUESTS 
Valor  por  omision:  False 

Fija  este  valor  a True  para  envolver  cada  petition  HTTP  request  en  una  sola 
transaction  de  la  base  de  datos. 

AUTOCOMMIT 
Valor  por  omision:  True 

Fija  este  valor  a False  si  quieres  desactivar  el  manejador  de  transacciones  de 
Django  e implementar  el  tuyo. 

ENGINE 

Valor  por  omision: " (cadena  vacla) 

Esta  variable  de  configuracion  indica  que  back-end  de  base  de  datos  debe 
usarse,  los  backends  incorporados  son: 

'django.db.  backends.  postgresql_psycopg2' 

'django.db.  backends,  mysql' 

'django.db. backends. sqlite3' 

'django.db.  backends. oracle' 

Puedes  usar  una  base  de  datos  como  backend  que  no  este  listada  en  Django 
configurando  ENGINE  con  la  ruta  completa  a tu  backend  (por  ejemplo 
mipaquete.backends.  whatever) . 

HOST 

Valor  por  omision: " (cadena  vacla) 

Esta  variable  de  configuracion  indica  el  dominio  debe  usarse  cuando  se 
establezca  una  conexion  a la  base  de  datos.  Una  cadena  vacia  significa 
localhost.  No  se  usa  con  SQLite. 

Si  este  valor  comienza  con  una  barra  (/)  y estas  usando  MySQL,  MySQL  se 
conectara  al  socket  via  un  socket  Unix: 
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"HOST":  '/var/run/mysql' 

Si  estas  usando  MySQL  este  valor  no  comienza  con  una  barra,  entonces  se 
asume  que  el  mismo  es  el  nombre  del  equipo. 

NAME 

Valor  por  omision: " (cadena  vacfa) 

El  nombre  de  la  base  de  datos  a usarse.  Para  SQLite,  es  la  ruta  completa  al 
archivo  de  la  base  de  datos. 

CONN_MAX_AGE 

Valor  por  omision:  0 

El  tiempo  de  vida  de  la  conexion  en  segundos.  Usa  0 para  cerrar  la  conexion  a 
la  base  de  datos  al  final  de  cada  petition  - el  comportamiento  historico  de 
Django  y None  para  conexiones  persistentes  ilimitadas. 

OPTIONS 

Valor  por  omision:  {}  (Diccionario  vacfo) 

Parametros  extra  a usarse  cuando  se  establece  la  conexion  a la  base  de  datos. 
Los  parametros  disponibles  varfan  dependiendo  de  la  base  de  datos. 

PASSWORD 

Valor  por  omision: " (cadena  vacfa) 

Esta  variable  de  configuration  es  la  contrasena  a usarse  cuando  se  establece 
una  conexion  a la  base  de  datos.  No  se  usa  con  SQLite. 

PORT 

Valor  por  omision: " (Cadena  vacia) 

El  puerto  a usarse  cuando  se  establece  una  conexion  a la  base  de  datos.  Una 
cadena  vacia  significa  el  puerto  por  omision.  No  se  usa  con  SQLite. 

USER 

Valor  por  omision: " (Cadena  vacfa) 

Esta  variable  de  configuration  es  el  nombre  de  usuario  a usarse  cuando  se 
establece  una  conexion  a la  base  de  datos.  No  se  usa  con  SQLite. 

TEST 


Valor  por  omision:  {} 
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Un  diccionario  de  configuraciones  para  pruebas  o test  en  la  base  de  datos. 


DATABASE_ROUTERS 
Valor  por  omision:  []  (Lista  vacfa) 

La  lista  de  routers  que  pueden  usarse  para  determinar  cual  base  de  datos  es  usada 
para  optimizar  las  consultas  a la  base  de  datos. 

DATE_FORMAT 

Valor  por  omision:  'N  j,  Y1  (por  ej.  Feb.  4, 2003) 

El  formato  a usar  por  omision  para  los  campos  de  fecha  en  las  paginas  lista  de 
cambios  en  el  sitio  de  administracion  de  Django  - y,  posiblemente,  por  otras  partes 
del  sistema.  Acepta  el  mismo  formato  que  la  etiqueta  now. 

Ver  tambien  DATETIME_FORMAT,  TIME_FORMAT,  YEAR_MONTH_FORMAT  y 
MONTH_DAY_FORMAT. 

DATETIME_FORMAT 

Valor  por  omision:  'N  j,  Y,  P'  (por  ej.  Feb.  4,  2003,  4 p.m.) 

El  formato  a usar  por  omision  para  los  campos  de  fecha-hora  en  las  paginas  lista  de 
cambios  en  el  sitio  de  administracion  de  Django  - y,  posiblemente,  por  otras  partes 
del  sistema.  Acepta  el  mismo  formato  que  la  etiqueta  now  ver  Apendice  F,  Tabla  F-2). 

Ver  tambien  DATE_FORMAT,  DATETIME_FORMAT,  TIME_FORMAT, 
YEAR_MONTH_FORMAT  y MONTH_DAY_FORMAT. 

DATE_INPUT_FORMATS 

Valor  por  omision: 

( 

’%Y-%m-%d’,  ’%m/%d/%Y’,  ’%m/%d/%y’,  # ’2006-10-25’,  ’10/25/2006’,  ’10/25/06’ 
’%b  %d  % Y’ , ’%b  %d,  % Y’ , # ’Oct  25  2006’,  ’Oct  25,  2006’ 

'%d  %b  % Y’ , ’%d  %b,  % Y’ , # ’25  Oct  2006’,  ’25  Oct,  2006’ 

■%B  %d  %Y’,  ’%B  %d,  %Y’,  # ’Octubre  25  2006’,  ’Octubre  25,  2006’ 

’%d  %B  % Y’ , ’%d  %B,  %Y’,  # ’25  Octubre  2006’,  ’25  Octubre,  2006’ 

) 

Una  tupla  de  formatos  que  seran  aceptados  al  introducir  datos  en  un  campo  date. 

DATETIME_FORMAT 

Valor  por  omision:  'N  j,  Y,  P1  (e.g.  Feb.  4,  2003,  4 p.m.) 

El  formato  predeterminado  para  mostrar  campos  tipo  fecha  o datetime  en  cualquier 
parte  del  sistema.  Nota  que  si  la  configuracion  local  USE_L10N  es  'True  esta  tendra 
mayor  precedencia. 
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DATETIME_INPUT_FORMATS 

Valor  por  omision: 

( 

'%Y-%m-%d  %H:%M:%S’,  # ’2006-10-25  14:30:59’ 
’%Y-%m-%d  % H : % M : %S . %f ’ , # ’2006-10-25  14:30:59.000200’ 
’%Y-%m-%d  %H:%M’,  # ’2006-10-25  14:30’ 

’%Y-%m-%d’,  # ’2006-10-25’ 

’%m/%d/%Y  %H:%M:%S’,  # ’10/25/2006  14:30:59’ 
’%m/%d/%Y  % H : % M : %S . %f ’ , # ’10/25/2006  14:30:59.000200’ 
'%m/%d/%Y  %H:%M’,  # ’10/25/2006  14:30’ 

’%m/%d/%Y’,  # ’10/25/2006’ 

’%m/%d/%y  %H:%M:%S’,  # ’10/25/06  14:30:59’ 

’%m/%d/%y  % H : % M : %S . %f ’ , # ’10/25/06  14:30:59.000200’ 
'%m/%d/%y  %H:%M’,  # ’10/25/06  14:30’ 

’%m/%d/%y’,  # ’10/25/06’ 

) 


Una  tupla  de  formatos  que  seran  aceptados  al  introducir  datos  en  un  campo 
datetime. 

DEBUG 

Valor  por  omision:  False 

Esta  variable  de  configuracion  es  un  Booleano  que  activa  y desactiva  el  modo  de 
depuracion. 

Si  defines  variables  de  configuracion  personalizadas,  django/ views /debug.py  tiene 
una  expresion  regular  HIDDEN_SETTINGS  que  ocultara  de  la  vista  DEBUG  todo 
aquello  que  contenga  SECRET,  PASSWORD  o PROFANITIES.  Esto  permite  que 
usuarios  en  los  que  no  se  confia  puedan  proveer  trazas  sin  ver  variables  de 
configuracion  con  contenido  importante  (u  ofensivo) . 

Sin  embargo,  nota  que  siempre  existiran  secciones  de  la  salida  de  depuracion  que 
son  inapropiadas  para  el  consumo  del  publico.  Rutas  de  archivos,  opciones  de 
configuracion  y similares  le  proveen  a potenciales  atacantes  information  extra  acerca 
de  tu  servidor.  Nunca  instales  un  sitio  con  DEBUG  activo. 

DEBUG_PROPAGATE_EXCEPTIONS 
Valor  por  omision:  False 

Si  se  establece  en  True  El  manejo  normal  que  Django  hace  de  las  excepciones  de  las 
funciones  de  vista  sera  suprimido.  Esto  puede  ser  util  para  algunos  tipos  de  pruebas, 
asegurate  de  solo  usarlo  en  desarrollo. 

DECIMAL_SEPARATOR 
Valor  por  omision: (Punto) 

El  separador  de  decimales  predeterminado,  usado  cuando  se  formatean  numeros 
decimales.  Nota  que  si  la  configuracion  local  USE_L10N  es  'True  esta  tendra  mayor 
precedencia. 
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DEFAULT_CHARSET 
Valor  por  omision:  'utf-8' 

El  conjunto  de  caracteres  a usar  por  omision  para  todos  los  objetos  HttpResponse  si 
no  se  especifica  en  forma  manual  un  tipo  MIME.  Se  usa  en  conjunto  con 
DEFAULT_CONTENT_TYPE  para  construir  la  cabecera  Content-Type. 

DEFAULT_CONTENT_TYPE 

Valor  por  omision:  'text/html' 

Tipo  de  contenido  a usar  por  omision  para  todos  los  objetos  ElttpResponse,  si  no  se 
especifica  manualmente  un  tipo  MIME.  Se  usa  en  conjunto  con  DEFAULT_CE1ARSET 
para  construir  la  cabecera  Content-Type.  Ver  el  Apendice  El  para  conocer  mas  acerca 
de  los  objetos  ElttpResponse. 

DEFAULT_EXCEPTION_REPORTER_FILTER 

Valor  por  omision:  django. views. debug. SafeExceptionReporterFilter 

Valor  predeterminado  para  el  filtro  encargado  del  manejo  de  reportes  de  exepciones 
usado  si  no  se  asigna  uno. 

DEFAULT_FILE_STORAGE 

Valor  por  omision:  django.core.files.storage.FileSystemStorage 

Clase  de  almacenamiento  de  archivos  predeterminado  para  usar  por  cualquiera  de 
las  operaciones  descritas,  que  no  especifiquen  un  sistema  en  particular  de 
almacenamiento. 

DEFAULT_FROM_EMAIL 

Valor  por  omision:  'webmaster@localhosf 

La  direction  de  correo  a usar  por  omision  para  correspondencia  automatizada 
enviada  por  el  administrador  del  sitio. 

DEFAULT_INDEX_TABLESPACE 

Valor  por  omision: " (Cadena  vacfa) 

Predeterminado  tablespace  para  usar  como  indice  en  campos  que  no  especifiquen 
uno,  si  la  base  de  datos  lo  soporta. 

DEFAULT_TABLESPACE 
Valor  por  omision: " (Cadena  vacfa) 

Predeterminado  tablespace  para  usar  en  modelos  que  no  especifiquen  uno,  si  la  base 
de  datos  lo  soporta. 
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DISALLOWED_USER_AGENTS 
Valor  por  omision:  ()  (Tupla  vacfa) 

Una  lista  de  objetos  expresiones  regulares  compiladas  que  representan  cadenas 
User-Agent  que  no  tiene  permitido  visitar  ninguna  pagina  del  sitio,  a nivel  global  para 
el  sitio.  Usa  la  misma  para  bloquear  robots  y crawlers  con  mal  comportamiento.  Se 
usa  unicamente  si  se  ha  instalado  CommonMiddleware  (ver  capltulo  17). 

EMAIL_BACKEND 

Valor  por  omision:  'django.core.mail.backends.smtp.EmailBackend' 

El  backend  usado  para  enviar. 

EMAIL_FILE_PATH 
Valor  por  omision:  No  definido 

El  directorio  usado  por  el  backend  de  emails  file  para  almacenar  archivos. 

EMAIL_HOST 
Valor  por  omision:  localhost' 

El  host  a usarse  para  enviar  e-mail.  Ver  tambien  EMAIL_PORT. 

EMAIL_HOST_PASSWORD 
Valor  por  omision: " (cadena  vacfa) 

La  contrasena  a usarse  para  el  servidor  SMTP  definido  en  EMAIL_HOST.  Esta  variable 
de  configuracion  se  usa  en  combinacion  con  EMAIL_HOST_USER  cuando  se  esta 
autenticando  ante  el  servidor  SMTP.  Si  alguna  de  estas  variables  de  configuracion 
esta  vacia,  Django  no  intentara  usar  autenticacion. 

Ver  tambien  EMAIL_HOST_USER. 

EMAIL_HOST_USER 

Valor  por  omision: " (cadena  vacfa) 

El  nombre  de  usuario  a usarse  para  el  servidor  SMTP  definido  en  EMAIL_HOST.  Si 
esta  vacio,  Django  no  intentara  usar  autenticacion.  Ver  tambien 
EMAIL_HOST_PASSWORD. 

EMAIL_PORT 
Valor  por  omision:  25 

El  puerto  a usarse  pata  el  servidor  SMTP  definido  en  EMAIL_HOST. 
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EMAIL_SUBJECT_P  REFIX 
Valor  por  omision:  '[Django]' 

El  prefijo  del  asunto  para  mensajes  de  e-mail  enviados  con 
django.core.mail.mail_admins  o django.core.mail.maiLmanagers.  Probablemente 
querras  incluir  un  espacio  al  final. 

FILE_CHARSET 

Valor  por  omision:  'utf-8' 

La  codification  del  caracteres  usada  para  decodificar  cualquier  archivo  leido  del 
disco.  Esto  incluye  archivos  de  plantillas  y licheros  de  datos  iniciales  SQL. 

FILE_UPLOAD_HANDLERS 

Valor  por  omision: 

("django. core. files.  uploadhandler.MemoryFileUploadHandler", 
"django.core.files.uploadhandler.TemporaryFileUploadHandler") 

Una  tupla  de  manejadores  usados  para  subir  archivos. 

FILE_UPLOAD_MAX_MEMORY_SIZE 
Valor  por  omision:  2621440  (i.e.  2.5  MB). 

El  tamano  maximo  (en  bytes)  que  se  permite  subir,  antes  de  usar  streamed  por  el 
sistema  de  archivos. 

FILE_UPLOAD_DIRECTORY_PERMISSIONS 

Valor  por  omision:  None 

El  modo  numerico  aplicado  a directorios  creados  en  el  proceso  de  subir  archivos. 

FILE_UPLOAD_TEMP_DIR 
Valor  por  omision:  None 

El  directorio  para  almacenar  datos  (en  particular  archivos  mas  grandes  que 
FILE_UPLOAD_MAX_MEMORY_SIZE)  temporalmente  cuando  se  suben  archivos.  Si 
es  None,  Django  usara  el  directorio  temporal  usado  por  el  sistema  operativo.  Por 
ejemplo,  en  sistemas  estilo-‘nix  el  valor  predeterminado  es:  /tmp. 

FIRST_DAY_OF_WEEK 

Valor  por  omision:  0 (Domingo) 

Numero  que  representa  el  primer  dia  de  la  semana.  Especialmente  util  cuando  se 
muestra  un  calendario.  Este  valor  unicamente  es  usado  cuando  se  usa  el  formato  de 
internationalization  o cuando  no  se  puede  encontrar  el  actual  formato  local. 
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Este  valor  debe  ser  un  entero  entre  0 y 6,  donde  0 es  Domingo,  1 es  lunes  y asi 
sucesivamente. 

FIXTURE_DIRS 

Valor  por  omision:  ()  (tupla  vacfa) 

Una  lista  de  ubicaciones  para  los  archivos  con  datos  de  fixtures,  en  el  orden  en  el  que 
se  buscara  en  las  mismas.  Nota  que  estas  rutas  deben  usar  barras  de  estilo  Unix,  aun 
en  Windows. 

IGNORABLE_404_ENDS 

Valor  por  omision:  ('mail.pl1,  'mailform.pl1,  'mail.cgi',  'mailform.cgi',  'favicon. ico',  '.php') 

Lista  de  expresiones  que  deben  ser  ignoradas.  Ver  IGNORABLE_404_URS. 

IGNORABLE_404_URLS 
Valor  por  omision:  () 

Lista  de  expresiones  regulares  compiladas  que  describen  las  URL  que  deben  ser 
ignoradas  cuando  se  reportan  errores  HTTP  404  via  email. 

INSTALLED_APPS 
Valor  por  omision:  ()  (tupla  vacfa) 

Una  tupla  de  cadenas  que  indican  todas  las  aplicaciones  que  estan  activas  en  esta 
instalacion  de 

Django.  Cada  cadena  debe  ser  una  ruta  completa  de  Python  hacia: 

• Una  clase  para  configurar  una  aplicacion,  o 

• Un  paquete  que  contiene  una  aplicacion. 

INTERNAL_IPS 

Valor  por  omision:  ()  (tupla  vacfa) 

Una  tupla  de  direcciones  IP,  como  cadenas,  que: 

• Pueden  ver  comentarios  de  depuracion  cuando  DEBUG  es  True. 

• Reciben  cabeceras  X si  esta  instalado  XViewMiddleware. 

LANGUAGES 

Valor  por  omision:  Una  tupla  de  todos  los  idiomas  disponibles.  Esta  lista  esta  en 
continuo  crecimiento  y cualquier  copia  que  incluyeramos  aqui  inevitablemente 
quedarfa  rapidamente  desactualizada.  Puedes  ver  la  lista  actual  de  idiomas 
traducidos  examinando  django/conf/global_settings.py,  o consulta  la 
documentation  online  disponible  en: 

(?)  https://github.com/django/django/blob/master/django/conf/global_settings.py). 
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La  lista  es  una  tupla  de  tuplas  de  dos  elementos  en  el  formato  (codigo  de  idioma, 
nombre  de  idioma)  - por  ejemplo,  ('ja',  'Japanese').  Especifica  que  idiomas  estan 
disponibles  para  la  seleccion  de  idioma.  Ver  el  capltulo  19  para  mas  information 
acerca  de  seleccion  de  idiomas. 

Generalmente,  el  valor  por  omision  deberia  ser  suficiente.  Solo  asigna  valor  a esta 
variable  de  configuration  si  deseas  restringir  la  seleccion  de  idiomas  a un 
subconjunto  de  los  idiomas  provistos  con  Django. 

Si  asignas  un  valor  personalizado  a LANGUAGES,  esta  permitido  marcar  los 
idiomas  como  cadenas  de  traduction,  pero  nunca  debes  importar 
django.utils.translation  desde  el  archivo  de  configuration,  porque  ese  modulo  a su 
vez  depende  de  la  configuration  y esto  crearia  una  importation  circular. 

La  solution  es  usar  una  funcion  gettextO  “boba”.  A continuation  un  archivo  de 
configuration  ejemplo: 

gettext  = lambda  s:  s 

LANGUAGES  = ( 

(’de’,  gettext(’German’)), 

(’en’,  gettext(’English’)), 

) 


Con  este  esquema,  make-messages.py  todavia  podra  encontrar  y marcar  esas 
cadenas  para  traduction,  pero  la  traduction  no  ocurrira  en  tiempo  de  ejecucion  - asi 
que  tendras  que  recordar  envolver  los  idiomas  con  la  gettextO  real  en  todo  codigo 
que  use  LANGUAGES  en  tiempo  de  ejecucion. 

MANAGERS 

Valor  por  omision:  ()  (tupla  vacla) 

Esta  tupla  esta  en  el  mismo  formato  que  ADMINS  que  especifica  quienes  deben 
recibir  notificaciones  de  enlaces  rotos  cuando  SEND_BROKEN_LINK_EMAILS  tiene 
el  valor  True. 

MEDIA_ROOT 

Default:  " (Empty  string)  Valor  por  omisidrr.  " (cadena  vacia)  La  ruta  absoluta  al 
directorio  del  sistema  que  contiene  los  archivos  subidos  por  los  usuarios 

Los  valores  para  MEDIA_ROOT  y STATIC_ROOT  deben  de  contener  valores 
distintos. 

MEDIA_URL 

Valor  por  omision: " (cadena  vacia) 

Esta  URL  maneja  los  medios  servidos  desde  MEDIA_ROOT  (por  ej. 
"http://media.lawrence.com"). 

Nota  que  esta  debe  tener  una  barra  final  si  posee  un  componente  de  ruta: 

Correcto:  "http://www.example.com/static/" 

Incorrecto:  http://www.example.com/static 

Para  usar  {{  MEDIA_URL  }}  en  las  plantillas,  es  necesario  configurar 
'django.core.context_processors. media'  en  el  TEMPLATE_CONTEXT_PROCESSORS. 
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MIDDLEWARE_CLASSES 
Valor  por  omision: 

('django. middleware. common.  CommonMiddleware', 

'django.  middleware. csrf.CsrfViewMiddleware') 

Una  tupla  de  clases  middleware  a usarse.  Ver  el  capltulo  17. 

MIGRATION_MODULES 
Valor  por  omision:  {}  # Un  diccionario  vacio 

Un  diccionario  que  especifica  los  paquetes  donde  los  modulos  de  migraciones  se 
pueden  encontrar,  uno  por  aplicacion.  El  valor  predeterminado  de  esta  configuracion 
es  un  diccionario  vacio,  pero  el  nombre  del  paquete  predeterminado  para  el  modulo 
de  migraciones  es  migrations. 

Ejemplo: 

{’blog’:  ’blog.db_migrations’} 

En  este  caso,  las  migraciones  relacionadas  con  la  aplicacion  blog  estaran 
contenidas  en  el  paquete  blog.db_migrations 

El  comando  makemigrations  automaticamente  crea  el  paquete  si  este  no  existe. 

MONTH_DAY_FORMAT 

Valor  por  omision:  'Fj' 

El  formato  a usar  por  omision  para  campos  de  fecha  en  las  paginas  de  lista  de 
cambios  en  la  aplicacion  de  administration  de  Django  - y,  probablemente,  en  otras 
partes  del  sistema  - en  casos  en  los  que  solo  se  muestran  el  mes  y el  dia.  Acepta  el 
mismo  formato  que  la  etiqueta  now. 

Por  ejemplo,  cuando  en  una  pagina  de  lista  de  cambios  la  aplicacion  de 
administration  de  Django  se  filtra  por  una  fecha,  la  cabecera  para  un  dia 
determinado  muestra  el  dia  y mes.  Diferentes  locales  tienen  diferentes  formatos.  Por 
ejemplo,  el  Ingles  de  EUA  tendria  “January  1”  mientras  que  Espanol  podrfa  tener  “1 
Enero”. 

Ver  tambien  DATE_FORMAT,  DATETIME_FORMAT,  TIME_FORMAT  y 
YEAR_MONTH_FORMAT. 

PREPEND_WWW 

Valor  por  omision:  False 

Esta  variable  de  configuracion  indica  si  se  debe  agregar  el  prefljo  de  subdominio 
“www.”  a URLs  que  no  lo  poseen.  Se  usa  unicamente  si  CommonMiddleware  esta 
instalado  (vercapitulo  17).  Ver  tambien  APPEND_S LASH. 

NUMBER_GROUPING 
Valor  por  omision:  0 

Numero  de  digitos  agrupados  juntos  en  la  parte  entera  de  un  numero. 
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De  uso  comun  para  visualizar  separadores  de  mil.  Si  la  configuration  es  0, 
entonces  no  se  aplicara  el  agrupamiento  a los  numeros.  Si  la  configuration  es  mas 
grande  que  0 entonces  THOUSAND_SEPARATOR  se  usara  para  separar  entre  esos 
grupos. 

Nota  que  si  el  valor  de  USE_L10N  esta  fijado  en  True,  el  formato  local  tendra 
precedencia  sobre  esta  configuration. 

ROOT_URLCONF 

Valor  por  omision:  No  definido 

Una  cadena  que  representa  la  ruta  completa  de  importation  Python  hacia  tu 
URLconfraiz  (por  ej.  "mydjangoapps.urls").  Ver  capitulo  3. 

STATIC_ROOT 
Valor  por  omision:  None 

La  ruta  absoluta  al  directorio  donde  se  recolectaran  los  archivos  estaticos  para  el 
despliegue,  usando  el  comando  collectstatic. 

Por  ejemplo:  "/var/www/example.com/static/" 

STATIC_URL 

Valor  por  omision:  None 

URL  usada  para  referirse  a la  ubicacion  de  los  archivos  estaticos  en  STATIC_ROOT. 
Por  ejemplo:  "/static/"  o http://static.example.com/ 

SECRET_KEY 

Valor  por  omision:  (Generado  automaticamente  cuando  creas  un  proyecto) 

Una  clave  secreta  para  esta  instalacion  particular  de  Django.  Es  usada  para  proveer 
una  semilla  para  los  algoritmos  de  hashing.  Asigna  un  valor  de  una  cadena  con 
caracteres  al  azar  - mientras  mas  larga  mejor.  django-admin  startproject  crea  una  en 
forma  automatica  y en  la  mayoria  de  los  casos  no  sera  necesario  que  la  modifiques. 

SEND_BROKEN_LINK_EMAILS 
Valor  por  omision:  False 

Esta  variable  de  configuration  indica  si  se  debe  enviar  un  e-mail  a los  MANAGERS 
cada  vez  que  alguien  visita  una  pagina  impulsada  por  Django  que  generara  un  error 
404  y que  posea  una  cabecera  referir  no  vacia  (en  otras  palabras  un  enlace  roto).  Es 
solamente  usado  si  esta  instalado  CommonMiddleware  (ver  capitulo  17). 

SERIALIZATION_MODULES 
Valor  por  omision:  No  definida. 

Un  diccionario  de  modulos  que  contiene  las  definiciones  de  serialization  (previstas 
como  strings)  Con  Have  para  un  identificador  de  cadena  para  el  tipo  de  serialization. 
Por  ejemplo,  para  definir  un  serializador  YAML,  usa: 
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SERIALIZATION_MODULES  = {'yaml':  'path.to.yaml_serializer'} 

SERVER_EMAIL 

Valor  por  omision:  ’root@  localhost1 

La  direction  de  e-mail  a usarse  como  remitente  para  los  mensajes  de  error,  tales 
como  los  enviados  a ADMINS  and  MANAGERS. 

SHORT_DATE_FORMAT 

Valor  por  omision:  m/d/Y  (e.g.  12/31/2003) 

Un  formato  disponible  que  puede  usarse  para  mostrar  campos  date  en  las  plantillas. 
Nota  que  si  USE_L10N  esta  fijado  en  True,  el  formato  local  tendra  mayor  precedencia 
yseraaplicado. 

SHORT_DATETIME_FORMAT 
Valor  por  omision:  m/d/Y  P (e.g.  12/31/2003  4 p.m.) 

Un  formato  disponible  que  puede  usarse  para  mostrar  campos  datetime  en  las 
plantillas.  Nota  que  si  USE_L10N  esta  fijado  en  True,  el  formato  local  tendra  mayor 
precedencia  y sera  aplicado. 

SIGNING_BACKEND 

Valor  por  omision:  'django.core.signing.TimestampSigner1 

El  backend  usado  para  firma  las  cookies  y otros  datos. 

SESSION_COOKIE_AGE 

Valor  por  omision:  1209600  (dos  semanas,  en  segundos) 

Esta  es  la  edad  de  las  cookies  de  sesion,  en  segundos.  Ver  capltulo  14. 

SESSION_COOKIE_DOMAIN 

Valor  por  omision : None 

El  dominio  a usarse  para  las  cookies  de  sesion.  Asigna  como  valor  una  cadena  tal 
como  ".lawrence.com"  para  cookies  inter-dominio,  o usa  None  para  una  cookie  de 
dominio  estandar.  Ver  capltulo  14. 

SESSION_COOKIE_NAME 
Valor  por  omision:  'sessionid' 

El  nombre  de  la  cookie  a usarse  para  las  sesiones;  puede  tener  el  valor  que  tu  desees. 
Ver  capitulo  14. 
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SESSION_COOKIE_SECURE 
Valor  por  omision:  False 

Esta  variable  de  configuracion  indica  si  debe  usarse  una  cookie  segura  para  la  cookie 
de  sesion.  Si  tiene  un  valor  True,  la  cookie  sera  marcada  como  “segura”,  lo  que 
significa  que  los  navegadores  podrian  asegurarse  que  la  cookie  solo  se  envie  via  una 
conexion  HTTPS.  Ver  capitulo  14. 

SESSION_EXPIRE_AT_BROWSER_CLOSE 

Valor  por  omision:  False 

Esta  variable  de  configuracion  indica  si  las  sesiones  deben  caducar  cuando  el  usuario 
cierre  su  navegador.  Ver  capitulo  12. 

SESSION_SAVE_EVERY_REQUEST 

Valor  por  omision:  False 

Esta  variable  de  configuracion  indica  si  la  sesion  debe  ser  grabada  en  cada  peticion. 
Ver  capitulo  14. 

SITE_ID 

Valor  por  omision:  No  definida. 

El  identificador,  como  un  entero,  del  sitio  actual  en  la  tabla  django_site  de  la  base  de 
datos.  Es  usada  de  manera  que  datos  de  aplicacion  puede  conectarse  en  sitio  (s) 
especifico(s)  y una  unica  base  de  datos  pueda  manejar  contenido  de  multiples  sitios. 
Ver  capitulo  14. 

TEMPLATE_CONTEXT_PROCESSORS 
Valor  por  omision: 

("django.contrib.auth.context_processors.auth", 

"django. core. context_processors. debug", 

"django.core.context_processors.il8n", 

"django. core. context_processors.  media", 

"django. core. context_processors. static", 

"django. core. context_processors.tz", 

"django. contrib.  messages. context_processors.  messages") 

Una  tupla  de  llamables  que  son  usados  para  poblar  el  contexto  en  RequestContext. 
Esos  llamables  reciben  como  argumento  un  objeto  peticion  y retornan  un  diccionario 
de  items  a ser  fusionados  con  el  contexto. 

TEMPLATE_DEBUG 


Valor  por  omision:  False 
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Este  Booleano  controla  el  estado  encendido/apagado  del  modo  de  depuration  de 
plantillas.  Si  es  True  la  pagina  de  error  vistosa  mostrara  un  reporte  detallado  para 
cada  TemplateSyntaxError.  Este  reporte  contiene  los  fragmentos  relevantes  de  la 
plantilla,  en  los  cuales  se  han  resaltado  las  llneas  relevantes. 

Nota  que  Django  solo  muestra  paginas  de  error  vistosas  si  DEBUG  es  True,  as!  que 
es  posible  que  desees  activar  dicha  variable  para  sacar  provecho  de  esta  variable. 

Ver  tambien  DEBUG. 

TEMPLATE_DIRS 

Valor  por  omision:  ()  (tupla  vacia) 

Un  lista  de  ubicaciones  de  los  archivos  de  codigo  fuente  de  plantillas,  en  el  orden  en 
el  que  seran  examinadas.  Notar  que  esas  rutas  deben  usar  barras  al  estilo  Unix,  aun 
en  Windows.  Ver  capltulo  4 y capltulo  10. 

TEMPLATE_LOADERS 
Valor  por  omision: 

('django. template,  loaders. filesystem. Loader', 

'django. template,  loaders. app_directories.  Loader') 

Una  tupla  de  cargadores  de  plantillas,  especificados  como  cadenas.  Cada  clase 
Loader  sabe  como  importar  plantillas  desde  un  particular  origen.  Opcionalmente, 
una  tupla  puede  usarse  en  lugar  de  una  cadena.  El  primer  item  en  la  tupla  debe  ser  el 
modulo  Loader  los  Items  subsecuentes  se  pasan  a Loader  durante  la  initialization. 

TEMPLATE_STRIN  G_IF_INVALID 

Valor  por  omision-.  " (cadena  vacia) 

La  salida,  como  una  cadena,  que  debe  usar  el  sistema  de  plantillas  para  variables 
invalidas  (por  ej.  con  errores  de  sintaxis  en  el  nombre).  Ver  Capltulo  10. 

TEST_RUNNER 

Valor  por  omision:  'django.test. simple. runjests1 

El  nombre  del  metodo  a usarse  para  arrancar  la  bateria  de  pruebas  (por  test  suite).  Es 
usado  por  el  framework  de  pruebas  de  Django,  el  cual  se  describe  en  linea  en 
http://www.djangoproject.com/. 

TIME_FORMAT 

Valor  por  omision:  'P'  (e.g.,  4 p.m.) 

El  formato  a usar  por  omision  para  los  campos  de  hora  en  las  paginas  lista  de 
cambios  en  el  sitio  de  administration  de  Django  - y,  posiblemente,  por  otras  partes 
del  sistema.  Acepta  el  mismo  formato  que  la  etiqueta  now  ver  Apendice  F,  Tabla  F-2). 

Ver  tambien  DATE_FORMAT,  DATETIME_FORMAT,  TIME_FORMAT, 
YEAR_MONTH_FORMAT  y MONTH_DAY_FORMAT. 
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TIME_ZONE 

Valor  por  omision:  'America/Chicago1 

Una  cadena  que  representa  la  zona  horaria  para  esta  instalacion  o None. 

Esta  es  la  zona  a la  cual  Django  convertira  todas  las  fechas/horas  - no 
necesariamente  la  zona  horaria  del  servidor.  Por  ejemplo,  un  servidor  podria  servir 
multiples  sitios  impulsados  por  Django,  cada  uno  con  una  configuracion  de  zona 
horaria  separada. 

Normalmente,  Django  fija  la  variable  os.environj'TZ']  a la  zona  horaria  que 
especificas  en  la  variable  de  configuracion  TIME_ZONE.  Por  lo  tanto,  todas  tus  vistas 
y modelos  operaran  automaticamente  en  la  zona  horaria  correcta.  Sin  embargo,  si 
estas  usando  el  metodo  de  configuracion  manual  (descrito  arriba  en  la  seccion 
“Usando  variables  de  configuracion  sin  fijar  DJANGO_SETTINGS_MODULE”  ) 
Django  no  tocara  la  variable  de  entorno  TZ  y quedara  en  tus  manos  asegurarte  de  que 
tus  procesos  se  ejecuten  en  el  entorno  correcto. 


Nota:  Django  no  puede  usar  en  forma  confiable  zonas  horarias  alternativas  en  un 
entorno  Windows.  Si  estas  ejecutando  Django  en  Windows  debes  asignar  a esta 
variable  un  valor  que  coincida  con  la  zona  horaria  del  sistema. 


USE_ETAGS 
Valor  por  omision:  False 

Este  Booleano  especilica  si  debe  generarse  la  cabecera  ETag.  La  misma  permite 
ahorrar  ancho  de  banda  pero  disminuye  el  rendimiento.  Se  usa  solamente  si  se  ha 
instalado  CommonMiddleware  (ver  capitulo  17). 

USE_I18N 

Valor  por  omision:  True 

Un  Booleano  que  especifica  si  debe  activarse  el  sistema  de  internacionalizacion  de 
Django  (ver  capitulo  19).  Provee  una  forma  sencilla  de  desactivar  la 
internacionalizacion,  para  mejorar  el  rendimiento.  Si  se  asigna  a esta  variable  el  valor 
False  Django  realizara  algunas  optimizaciones  de  manera  que  no  se  cargue  la 
maquinaria  de  internacionalizacion. 

USE_L10N 

Valor  por  omision:  False 

Un  Booleano  que  especilica  si  debe  activarse  el  sistema  de  localizacion  de  Django 
(ver  capitulo  19 ■ Si  se  fija  a True  Django  mostrara  numeros  y fechas  usando  el 
formato  de  la  localizacion  actual. 

Nota: 

El  archivo  settings.py  creado  por  django-admin  startproject  incluye  por  conveniencia 
USE_L10N  = True. 

USE_TZ 


Valor  por  omision:  False 
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Un  valor  booleano  que  especifica  si  se  tendran  en  cuenta  los  formatos  de  fecha  y 
tiempo  por  defecto  o no.  Django  toma  en  cuenta  los  formatos  de  fechas  y tiempos 
internamente  de  otra  forma  Django  usara  los  valores  en  tiempo  local. 


Nota:  El  archivo  settings.py  creado  por  django-admin  startproject  incluye  por 
conveniencia  USE_TZ  = True. 


WSGI_APPLI  CATION 

Valor  por  omision:  None 

La  ruta  completa  al  objeto  incorporado  ‘WSGI  application’  que  Django  sirve,  usando 
(e.g.  runserver)  El  comando  d j ad m i n : django-admin  startproject  <startproject>  crea 
un  simple  archivo  wsgi.py  con  un  llamable  llamado  application  y apunta  a este  a la 
configuration  de  application. 

Si  no  se  fija,  el  valor  se  usara  el  valor  de  retorno  de 
django.core.wsgi.get_wsgi_application().  En  este  caso  el  comportamiento  de 
runserver  sera  identico  al  de  versiones  anteriores  de  Django. 


YEAR_MONTH_FORMAT 

Valor  por  omision:  'FY' 

El  formato  a usar  por  omision  para  los  campos  de  fecha  en  la  pagina  de  lista  de 
cambios  en  el  sitio  de  administration  de  Django  - y,  posiblemente,  por  otras  partes 
del  sistema,  en  los  casos  en  los  que  solo  se  muestran  el  mes  y el  ano.  Acepta  el  mismo 
formato  que  la  etiqueta  nowve r Apendice  F). 

Por  ejemplo,  cuando  se  esta  filtrando  una  pagina  lista  de  cambios  de  la  aplicacion 
de  administration  de  Django  mediante  un  detalle  de  fecha,  la  cabecera  de  un  mes 
determinado  muestra  el  mes  y el  ano.  Los  distintos  locales  tienen  diferentes 
formatos.  Por  ejemplo,  el  ingles  de  EUA  usarfa  “January  2006”  mientras  que  otro 
locale  podria  usar  “2006/January”. 


APENDICE  E 


Etiquetas  de  plantilla  y filtros 
predefinidos 


E n el  capitulo  4 se  hace  una  introduccion  a las  etiquetas  de  plantilla  y filtros 
mas  utilizados,  pero  Django  incorpora  muchos  mas.  En  este  apendice  se  listan  toda 
las  que  estaban  incluidas  en  el  momento  en  que  se  escribio  el  libro,  pero  se 
anaden  nuevas  etiquetas  y filtros  de  forma  regular. 

La  mejor  referencia  de  todas  las  etiquetas  y filtros  disponibles  se  encuentra  en  la 
propia  pagina  de  administracion.  Alii  se  incluye  una  referencia  completa  de  todas  las 
etiquetas  y filtros  que  hay  disponibles  para  una  determinada  aplicacion.  Para  verla, 
solo  tienes  que  pulsar  con  el  raton  en  el  enlace  de  documentacion  que  esta  en  la 
esquina  superior  derecha  de  la  pagina. 

Las  secciones  de  etiquetas  y filtros  de  esta  documentacion  incluiran  tanto  las 
etiquetas  y filtros  predefinidos  (de  hecho,  las  referencias  de  este  apendice  vienen 
directamente  de  ahi)  como  aquellas  etiquetas  y filtros  que  se  hayan  incluido  o escrito 
para  la  aplicacion. 

Este  apendice  sera  mas  util,  por  tanto,  para  aquellos  que  no  dispongan  de  acceso  a 
la  interfaz  de  administracion.  Como  Django  es  altamente  configurable,  las 
indicaciones  de  la  interfaz  de  administracion  deben  ser  consideradas  como  la 
documentacion  mas  actualizada  y,  por  tanto,  la  de  mayor  autoridad. 


Etiquetas  predefinidas 

autoescape 

Controla  el  comportamiento  actual  del  auto-escape.  Esta  etiqueta  toma  como 
argumento  tanto  a:  on  y off  y determina  si  el  auto-escapeo  estan  dentro  del  bloque. 

Cuando  el  auto-escapeo  esta  activado,  todas  las  variables  contenidas  que  contenga 
E1TML  seran  escapadas  antes  de  mostrar  el  resultado  de  la  salida  (pero  despues  de 
que  cualquier  filtro  se  haya  aplicado).  Esto  es  equivalente  a manualmente  aplicar  el 
filtro  escape  a cada  variable. 

La  unica  exception  son  las  variables  que  estan  marcadas  como  “safe”  para 
autoescape,  ya  sea  por  la  clave  que  poblo  la  variable,  o porque  se  ha  aplicado  el  filtro 
safe  o escape. 

Forma  de  usarlo: 

{%  autoescape  on  %} 

{{body}} 

{%  endautoescape  %} 
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block 

Define  un  bloque  que  puede  ser  sobrescrito  por  las  plantillas  derivadas.  Vease  la 
section  acerca  de  herencia  de  plantillas  en  el  capltulo  4 para  mas  informacion. 

comment 

Ignora  todo  lo  que  aparece  entre  {%  comment  %}  y {%  endcomment  %}.  Como  nota 
opcional,  se  puede  insertar  en  la  primera  etiqueta.  Por  ejemplo,  es  util  para  comentar 
fuera  del  codigo  para  documentar,  porque  el  codigo  fue  deshabilitado. 

Ejemplo  de  su  uso: 

<p>Renderizar  texto  con  {{ fecha_publicacion|date:"c"  }}</p> 

{%  comment  "Nota  opcional"  %} 

<p>Comentado  fuera  del  texto  creado|date:"c"  }}</p> 

{%  endcomment  %} 

csrf_token 

Esta  etiqueta  es  usada  para  protection  CSRF. 

cycle 

Rota  una  cadena  de  texto  entre  diferentes  valores,  cada  vez  que  aparece  la  etiqueta. 

Dentro  de  un  bucle,  el  valor  rota  entre  los  distintos  valores  disponibles  en  cada 
iteration  del  bucle: 

{%  for  o in  somejist  %} 

<tr  class="{%  cycle  rowl,row2  %}"> 

</tr> 

{%  endfor  %} 

Fuera  de  un  bucle,  hay  que  asignar  un  nombre  unico  la  primera  vez  que  se  usa  la 
etiqueta,  y luego  hay  que  incluirlo  ese  nombre  en  las  sucesivas  llamadas: 

<tr  class="{%  cycle  rowl,row2,row3  as  rowcolors  %}">.. ,</tr> 

<tr  class="{%  cycle  rowcolors  %}">... </tr> 

<tr  class="{%  cycle  rowcolors  %}">... </tr> 

Se  pueden  usar  cualquier  numero  de  valores,  separandolos  por  comas.  Asegurate 
de  no  poner  espacios  entre  los  valores,  solo  comas. 

debug 

Muestra  un  monton  de  informacion  para  depuration  de  errores,  incluyendo  el 
contexto  actual  y los  modulos  importados. 

extends 

Sirve  para  indicar  que  esta  plantilla  extiende  una  plantilla  padre. 

Esta  etiqueta  se  puede  usar  de  dos  maneras: 
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• {%  extends  "base.html"  %}  (Con  las  comillas)  interpreta  literalmente 
"base.html"  como  el  nombre  de  la  plantilla  a extender. 

• {%  extends  variable  %}  usa  el  valor  de  variable.  Si  la  variable  apunta  a una 
cadena  de  texto,  Django  usara  dicha  cadena  como  el  nombre  de  la  plantilla 
padre.  Si  la  variable  es  un  objeto  de  tipo  Template,  se  usara  ese  mismo  objeto 
como  plantilla  base. 

En  el  capitulo  4 podras  encontrar  muchos  ejemplo  de  uso  de  esta  etiqueta. 

filter 

Filtra  el  contenido  de  una  variable. 

Los  filtros  pueden  ser  encadenados  sucesivamente  (La  salida  de  uno  es  la  entrada 
del  siguiente),  y pueden  tener  argumentos,  como  en  la  sintaxis  para  variables 
He  aqui  un  ejemplo: 

{%  filter  escape|lower  %} 

Este  texto  sera  escapado  y aparecera  en  minusculas 

{%  endfilter  %} 

firstof 

Presenta  como  salida  la  primera  de  las  variables  que  se  le  pasen  que  evalue  como  no 
falsa.  La  salida  sera  nula  si  todas  las  variables  pasadas  valen  False. 

He  aqui  un  ejemplo: 

{%  firstof  varl  var2  var3  %} 

Equivale  a: 

{%  if  varl  %} 

{{ varl }} 

{%  else  %}{%  if  var2  %} 

{{ var2 }} 

{%  else  %}{%  if  var3  %} 

{{ var3 }} 

{%  end  if  %}{%  end  if  %}{%  end  if  %} 

for 

Itera  sobre  cada  uno  de  los  elementos  de  un  lista  o array.  Por  ejemplo,  para  mostrar 
una  lista  de  libros,  cuyos  titulos  esten  en  la  listajibros,  podriamos  hacer  esto: 

<ul> 

{%  for  libro  in  listajibros  %} 

<li>{{  libro. titulo  }}</li> 

{%  endfor  %} 

</ul> 


%} 


Tambien  se  puede  iterar  la  lista  en  orden  inverso  usando  {%  for  obj  in  list  reversed 
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Dentro  de  un  bucle,  la  propia  sentencia  for  crea  una  serie  de  variables.  A estas 
variables  se  puede  acceder  unicamente  dentro  del  bucle.  Las  distintas  variables  se 
explican  en  la  Tabla  E-l. 


Variable 


Description 


forloop.counter 

forloop.counterO 

forloop.revcounter 

forloop.revcounterO 

forloop.first 

forloop.last 

forloop.parentloop 


El  numero  de  vuelta  o iteracion  actual  (usando  un  indice 
basado  en  1). 

El  numero  de  vuelta  o iteracion  actual  (usando  un  Indice 
basado  en  0). 

El  numero  de  vuelta  o iteracion  contando  desde  el  fin  del  bucle 
(usando  un  indice  basado  en  1). 

El  numero  de  vuelta  o iteracion  contando  desde  el  fin  del  bucle 
(usando  un  indice  basado  en  0). 

True  si  es  la  primera  iteracion. 

True  si  es  la  ultima  iteracion. 

Para  bucles  anidados,  es  una  referencia  al  bucle  externo. 


Tabla  E 1 : Variables  accesibles  dentro  de  bucles  { % for  %} 

for ...  empty 


La  etiqueta  for  toma  una  clausula  opcional  {%  empty  %}  cuando  el  texto  es  mostrado, 
si  el  array e sta  vacio  o no  puede  ser  encontrado. 

<ul> 

{%  for  atleta  in  lista_atletas  %} 

<li>{{  atleta. nombre  }}</li> 

{%  empty  %} 

<li>Lo  sentimos,  no  hay  atletas  en  esta  lista.</li> 

{%  endfor  %} 

</ul> 

El  ejemplo  anterior  es  equivalente  a (pero  mas  corto,  limpio  y posiblemente  mas 
rapido)  a lo  siguiente: 

<ul> 

{%  if  lista_atletas  %} 

{%  for  atleta  in  lista_atletas  %} 

<li>{{  atleta.nombre  }}</li> 

{%  endfor  %} 

{%  else  %} 

<li>Lo  sentimos,  no  hay  atletas  en  esta  lista.</li> 

{%  endif  %} 

</ul> 

If 

La  etiqueta  {%  if  %}  evalua  una  variable.  Si  dicha  variable  se  evalua  como  una 
expresion  “verdadera”  (Es  decir,  que  el  valor  exista,  no  este  vacia  y no  es  el  valor 
booleano  False),  se  muestra  el  contenido  del  bloque: 


{%  if  lista_atletas  %} 
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Numero  de  atletas:  Jista_atletas|length  }} 

{%  else  %} 

No  hay  atletas. 

{%  end  if  %} 

Si  la  lista  lista_atletas  no  esta  vacia,  podemos  mostrar  el  numero  de  atletas  con  la 
expresion  {{ lista_atletas|length }} 

Ademas,  como  se  puede  ver  en  el  ejemplo,  la  etiqueta  if  puede  tener  un  bloque 
opcional  {%  else  %}  que  se  mostrara  en  el  caso  de  que  la  evaluacion  de  falso. 

Operadores  booleanos 

Las  etiquetas  if  pueden  usar  operadores  logicos  como  and,  or  y not  para  evaluar 
expresiones  mas  complejas: 

{%  if  lista_atletas  and  lista_entrenadores  %} 

Los  atletas  y los  entrenadores  estan  disponibles 

{%  end  if  %} 

{%  if  not  lista_atletas  %} 

No  hay  atletas. 

{%  endif  %} 

{%  if  lista_atletas  or  lista_entrenadores  %} 

Hay  algunos  atletas  o algunos  entrenadores. 

{%  endif  %} 

{%  if  not  lista_atletas  or  lista_entrenadores  %} 

No  hay  atletas  o hay  algunos  entrenadores 
{%  endif  %} 

{%  if  lista_atletas  and  not  lista_entrenadores  %} 

Hay  algunos  atletas  y absolutamente  ningun  entrenador. 

{%  endif  %} 

La  etiqueta  if  no  admite,  sin  embargo,  mezclar  los  operadores  and  y or  dentro  de  la 
misma  comprobacion,  porque  la  orden  de  aplicacion  de  los  operadores  logicos  seria 
ambigua.  Por  ejemplo,  el  siguiente  codigo  es  invalido: 

{%  if  lista_atletas  and  lista_entrenadores  or  lista_animadoras  %} 

Para  combinar  operadores  and  y or,  puedes  usar  sentencias  if  anidadas,  como  en  el 
siguiente  ejemplo: 

{%  if  lista_atletas  %} 

{%  if  lista_entrenadores  or  lista_animadoras  %} 

iTenemos  atletas,  y ya  sea  entrenadores  o porristas! 

{%  endif  %} 

{%  endif  %} 

Es  perfectamente  posible  usar  varias  veces  un  operador  logico,  siempre  que  sea  el 
mismo  siempre.  Por  ejemplo,  el  siguiente  codigo  es  valido: 

{%  if  lista_atletas  or  lista_entrenadores  or  lista_animadoras  or  lista_profesores  %} 
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Las  etiquetas  if  pueden  usarse  con  operadores  ==,  !=,  <,  >,  <=,  >=  e in,  los  cuales 
funcionan  de  la  siguiente  forma: 

operador:  == 

Igualdad.  Por  ejemplo: 


{%  if  mivariable  ==  "x"  %} 

Esta  variable  aparece  si  “mivariable"  es  igual  a la  cadena  "x" 

{%  end  if  %} 

operador:  != 

Desigualdad.  Por  ejemplo: 


{%  if  mi_variable  !=  "x"  %} 

Esta  cadena  aparece  si  mi  “mi_variable“  no  es  igual  a la  cadena  "x", 
o si  “mi_variable“  no  se  encuentra  en  el  contexto. 

{%  end  if  %} 

operador:  < 

Menor  que.  Por  ejemplo: 

{%  if  mi_variable  < 100  %} 

Esta  cadena  aparece  si  “mi_variable“  es  menor  que  100. 

{%  end  if  %} 

operador:  > 

Mayor  que.  Por  ejemplo: 

{%  if  mi_variable  > 0 %} 

Esta  cadena  aparece  si  “mi_variable“‘es  mayor  que  0. 

{%  endif  %} 

operador:  <= 

Menor  o igual  a.  Por  ejemplo: 

{%  if  “mi_variable“  <=  100  %} 

Esta  cadena  aparece  si  “mi_variable“  es  menor  o igual  a 100. 

{%  endif  %} 

operador:  >= 

Mayor  o igual  a.  Por  ejemplo: 


{%  if  “mi_variable“  >=  1 %} 

Esta  cadena  aparece  si  “mi_variable“  es  mayor  o igual  que  1. 

{%  endif  %} 
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operador:  in 

Contenido  dentro.  Este  operador  es  soportado  por  muchos  contenedores  Python 
para  probar  si  el  valor  dado  esta  en  el  contenedor.  Los  siguientes  son  algunos 
ejemplos  sobre  como  x in  y son  interpretados. 

{%  if  "be"  in  "abedef"  %} 

Esto  aparece  si  "be"  es  una  subcadena  de  "abedef" 

{%  endif  %} 

{%  if  "hola"  in  saludos  %} 

Si  saludos  es  una  lista  o un  conjunto  de  elementos,  donde  uno  de  los 
elementos  de  la  cadena  es  "hola",  entonces  aparecera. 

{%  endif  %} 

{%  if  usuario  in  usuarios  %} 

Si  usuarios  es  un  QuerySet,  este  aparecera  si  el  usuario  es  un  instancia 
que  pertenece  a el  QuerySet. 

{%  endif  %} 

operador:  not  in 

No  contenido  dentro.  Esta  es  la  negation  del  operador  in. 

El  operador  de  comparacion  no  puede  ‘encadenar’  como  en  Python  en  notation 
Matematica.  Por  ejemplo  en  lugar  de  usar  esto: 

{%  if  a > b > c %}  (MAL) 

Debes  hacer  esto: 

{%  if  a > b and  b > c %} 


Filtros 

Puedes  usar  filtros  en  las  expresiones  if. 

Por  ejemplo: 

{%  if  messages|length  >=  100  %} 
jHoy  tienes  montones  de  mensajes! 

{%  endif  %} 

Expresiones  complejas 

Todo  lo  anterior  se  puede  combinar  para  formar  expresiones  complejas.  Para  tales 
expresiones,  puede  ser  importante  saber  como  agrupar  los  operadores  cuando  se 
evaluan  las  expresiones  - es  decir,  conocer  las  reglas  de  prioridad.  La  precedencia  de 
los  operadores,  desde  lo  mas  bajo  a lo  mas  alto  posible,  es  como  sigue: 

■ or 

■ and 

■ not 

■ in 

■ ==,  !=,  <,  >,  <=,  >= 
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(Esto  funciona  exactamente  como  en  Python).  Por  ejemplo,  la  siguiente  etiqueta  if 
en  Django: 


{%  if  a ==  b or  c ==  d and  e %} 


En  Python  se  escribiria  asi: 

(a  ==  b)  or  ((c  ==  d)  and  e) 

Si  necesitas  usar  diferentes  prioridades,  necesitas  jerarquizar  las  etiquetas  if. 
Algunas  veces  eso  es  mejor  para  obtener  mayor  claridad,  de  cualquier  manera,  es 
necesario  conocer  las  reglas  de  precedencia  o prioridad. 

ifchanged 

Comprueba  si  el  valor  ha  cambiado  desde  la  ultima  iteration  al  bucle. 

El  bloque  de  etiqueta  {%  ifchanged  %}  es  usado  con  bucles.  Tiene  dos  posibles 
usos: 

1.  Comprueba  el  contenido  dado  contra  el  estado  previo  y solo  exhibe  el 
contenido  si  ha  cambiado.  Por  ejemplo,  esto  muestra  una  lista  de  dias, 
unicamente  si  cambia  el  mes. 

<hl>Archivos  del  { year  }}</hl> 

{%  for  date  in  days  %} 

{%  ifchanged  %}<h3>{{  date|date:"F"  }}</h3>{%  endifchanged  %} 

<a  href="{{  date|date:"M/d"|lower  }}/">{{  date|date:"j"  }}</a> 

{%  endfor  %} 

2.  Si  se  le  pasan  una  o mas  variables,  verifica  cualquier  variable  que  haya 
cambiado.  El  siguiente  ejemplo  muestra  la  fecha  cada  vez  que  cambia, 
mientras  que  muestra  la  hora  si  la  fecha  y la  hora  cambian: 

{%  for  date  in  days  %} 

{%  ifchanged  date. date  %}  {{  date. date  }}  {%  endifchanged  %} 

{%  ifchanged  date. hour  date. date  %} 

{{ date. hour }} 

{%  endifchanged  %} 

{%  endfor  %} 

Tambien  puede  aceptar  opcionalmente  una  clausula  {%  else  %}  que  muestra 
si  el  valor  no  ha  cambiado. 

{%  for  match  in  matches  %} 

<div  style="background-color: 

{%  ifchanged  match. bal lot Jd  %} 

{%  cycle  "red"  "blue"  %} 

{%  else  %} 
gray 

{%  endifchanged  %} 

">{{  match  }}</div> 

{%  endfor  %} 
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ifequal 

Muestra  el  contenido  del  bloque  si  los  dos  argumentos  suministrados  son  iguales. 

He  aqui  un  ejemplo: 

{%  ifequal  user. id  comment.userjd  %} 

{%  endifequal  %} 

A1  igual  que  con  la  etiqueta  {%  if  %},  existe  una  clausula  {%  else  %}  opcional. 

Los  argumentos  pueden  ser  cadenas  de  texto,  asi  que  el  siguiente  codigo  es  valido: 

{%  ifequal  user. username  "adrian"  %} 

{%  endifequal  %} 

Un  uso  alternativo  para  la  etiqueta  ifequal  es  usarlo  con  la  etiqueta  if  y el  operador 


ifnotequal 

Es  igual  que  ifequal,  excepto  que  comprueba  que  los  dos  parametros  suministrados 
no  sean  iguales. 

Una  alternativa  para  usar  la  etiqueta  ifnotequal  es  usandola  con  la  etiqueta  if  y el 
operador  !=. 

include 

Carga  una  plantilla  y la  representa  usando  el  contexto  actual.  Es  una  forma  de 
“incluir”  una  plantilla  dentro  de  otra. 

El  nombre  de  la  plantilla  puede  o bien  ser  el  valor  de  una  variable  o estar  escrita  en 
forma  de  cadena  de  texto,  rodeada  ya  sea  con  comillas  simples  o comillas  dobles,  a 
gusto  del  lector. 

El  siguiente  ejemplo  incluye  el  contenido  de  la  plantilla  "foo/bar.html": 

{%  include  "foo/bar.html"  %} 

Este  otro  ejemplo  incluye  el  contenido  de  la  plantilla  cuyo  nombre  sea  el  valor  de  la 
variable  template_name: 

{%  include  template_name  %} 

load 

Carga  una  biblioteca  de  plantillas.  En  el  capitulo  9 puedes  encontrar  mas 
information  acerca  de  las  bibliotecas  de  plantillas. 

Por  ejemplo,  la  siguiente  plantilla  carga  todas  las  etiquetas  y filtros  registrados  en 
libreria  y otra_  libreria  localizada  en  el  paquete  pack: 

{%  load  libreria  pack.olrajibreria  %} 

Tambien  se  pueden  cargar  selectivamente  filtros  de  forma  individual  o etiquetas 
de  alguna  libreria  usando  el  argumento  from.  En  este  ejemplo  las  plantillas  de 
etiquetas /filtros  llamada  foo  y bar  seran  cargados  del  paquete  algunalibreria: 
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{%  load  too  bar  from  algunalibreria  %} 

lorem 

Muestra  en  orden  aleatorio  el  texto  en  Latin  “lorem  ipsum”.  Esto  puede  ser  util  para 
proveer  datos  en  las  plantillas. 

Uso: 

{%  lorem  [count]  [method]  [random]  %} 

La  etiqueta  {%  lorem  %}  puede  usarse  con  cero,  uno,  dos  o tres  argumentos.  Los 
argumentos  son: 


Argumento  Description 


count  Un  numero  (o  variable)  que  contiene  el  numero  de  parrafos  o palabras 

para  generar  (el  valor  predeterminado  es  1). 

method  Lisa  w para  palabras,  p para  parrafos  en  HTML  o b para  bloques  de 
texto  (el  valor  predeterminado  es  b). 

random  La  palabra  random,  la  cual  si  es  dada,  no  usa  el  comun  parrafo  (“Lorem 
ipsum  dolor  sit  amet.JO  cuando  genera  texto. 

Tabla  E2:  Argumentos  dela  etiqueta  lorem. 


Ejemplos: 

{%  lorem  %}  la  salida  con  el  comun  parrafo:  “lorem  ipsum”. 

{%  lorem  3 p %}"la  salida  con  el  comun  parrafo:  "lorem  ipsum"  y dos  parrafos 
al  azar  en  HTML  y con  etiquetas  "<p>. 

{%  lorem  2 w random  %}  la  salida  seran  dos  palabras  en  latfn  al  azar. 


now 

Muestra  la  fecha,  escrita  de  acuerdo  a un  formato  indicado. 

Esta  etiqueta  fue  inspirada  por  la  funcion  date()  de  PHP(),  y utiliza  el  mismo 
formato  que  esta  ( (%)  http://php.net/date).  La  version  Django  tiene,  sin  embargo, 
algunos  extras. 

He  aqui  un  ejemplo: 

Es  el  {%  now  "jS  F Y H:i"  %} 

Se  pueden  escapar  los  caracteres  de  formato  con  una  barra  invertida,  si  se  quieren 
incluir  de  forma  literal.  En  el  siguiente  ejemplo,  se  escapa  el  significado  de  la  letra  “f” 
con  la  barra  invertida,  ya  que  de  otra  manera  se  interpretaria  como  una  indication  de 
incluir  la  hora.  La  “o”,  por  otro  lado,  no  necesita  ser  escapada,  ya  que  no  es  un 
caracter  de  formato: 

Es  el  {%  now  "jS  o\f  F"  %} 

El  ejemplo  mostraria:  “Es  el  4th  of  September”. 
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regroup 

Reagrupa  una  lista  de  objetos  similares  usando  un  atributo  comun. 

Para  comprender  esta  etiqueta,  es  mejor  recurrir  a un  ejemplo.  Digamos  que  gente 
es  una  lista  de  objetos  de  tipo  Persona,  y que  dichos  objetos  tienen  los  atributos 
nombre,  apellido  y genero.  Queremos  mostrar  un  listado  como  el  siguiente: 

• Hombre: 

o George  Bush 
o Bill  Clinton 


• Mujeres: 

o Margaret  Thatcher 
o Condoleezza  Rice 

• Desconocido: 

o Pat  Smith 

El  siguiente  fragmento  de  plantilla  mostrarfa  como  realizar  esta  tarea: 

{%  regroup  gente  by  genero  as  grouped  %} 

<ul> 

{%  for  group  in  grouped  %} 

<li>{{  group. grouper }} 

<ul> 

{%  for  item  in  group. list  %} 

<li>{{  item  }}</li> 

{%  endfor  %} 

</ul> 

</li> 

{%  endfor  %} 

</ul> 

Como  puedes  ver,  {%  regroup  %}  crea  una  nueva  variable,  que  es  una  lista  de 
objetos  que  tienen  dos  tributos,  grouper  y list.  En  grouper  se  almacena  el  valor  de 
agrupacion,  list  contiene  una  lista  de  los  objetos  que  tenian  en  comun  al  valor  de 
agrupacion.  En  este  caso,  grouper  podria  valer  Male,  Female  y Unknown,  y list  serfa 
una  lista  con  las  personas  correspondientes  a cada  uno  de  estos  sexos. 

Elay  que  destacar  que  {%  regroup  %}  no  funciona  correctamente  cuando  la  lista  no 
esta  ordenada  por  el  mismo  atributo  que  se  quiere  agrupar.  Esto  significa  que  si  la 
lista  del  ejemplo  no  esta  ordenada  por  el  sexo,  debes  asegurarte  de  que  se  ordene 
antes  correctamente,  por  ejemplo  con  el  siguiente  codigo: 

{%  regroup  gente|dictsort:"genero"  by  genero  as  grouped  %} 


spaceless 

Elimina  los  espacios  en  bianco  entre  etiquetas  E1TML  Esto  incluye  tabuladores  y 
saltos  de  linea. 

El  siguiente  ejemplo: 
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{%  spaceless  %} 

<p> 

<a  href="foo/">Foo</a> 

</p> 

{%  endspaceless  %} 

Retornaria  el  siguiente  codigo  HTML: 

<p><a  href="foo/">Foo</a></p> 

Solo  se  eliminan  los  espacios  entre  las  etiquetas,  no  los  espacios  entre  la  etiqueta  y 
el  texto.  En  el  siguiente  ejemplo,  no  se  quitan  los  espacios  que  rodean  la  palabra 
Hello: 

{%  spaceless  %} 

<strong> 

Hola 

</strong> 

{%  endspaceless  %} 

ssi 

Muestra  el  contenido  de  un  fichero  determinado  dentro  de  la  pagina. 

Al  igual  que  la  etiqueta  “include”,  {%  ssi  %}  incluye  el  contenido  de  otro  fichero 
(que  debe  ser  especificado  usando  una  ruta  absoluta)  en  la  pagina  actual: 

{%  ssi  /home/html/ljworld.com/includes/right_generic.html  %} 

Si  se  le  pasa  el  parametro  opcional  “parsed”,  el  contenido  del  fichero  incluido  se 
evalua  como  si  fuera  codigo  de  plantilla,  usando  el  contexto  actual: 

{%  ssi  /home/html/ljworld.com/includes/right_generic.html  parsed  %} 

Para  poder  usar  la  etiqueta  {%  ssi  %},  hay  que  definir  el  valor 
ALLO  WED_  IN  CL  UDE_  ROO  TS  e n los  ajustes  de  Django,  como  medida  de  seguridad. 

La  mayor  parte  de  las  veces,  {%  include  %}  funcionara  mejor  que  {%  ssi  %};  esta  se 
ha  incluido  solo  para  garantizar  compatibilidad  hacia  atras. 

templatetag 

Permite  representar  los  caracteres  que  estan  definidos  como  parte  del  sistema  de 
plantillas. 

Como  el  sistema  de  plantillas  no  tiene  el  concepto  de  “escapar”  el  significado  de 
las  combinaciones  de  simbolos  que  usa  internamente,  tenemos  que  recurrir  a la 
etiqueta  {%  templatetag  %}  si  nos  vemos  obligados  a representarlos. 

Se  le  pasa  un  argumento  que  indica  que  combinacion  de  simbolos  debe  producir. 
Los  valores  posibles  del  argumento  se  muestran  en  la  tabla  E-4. 
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openblock 

closeblock 


{% 

%} 

{{ 

}} 


openvariable 

closevariable 


openbrace 

closebrace 


opencomment 

closecomment 


{# 

#} 


Tabla  F4:  Argumentos  validos  de  templatetag 


Ejemplo  de  su  uso: 

{%  templatetag  openblock  %}  url  'lista_entradas'  {%  templatetag  closeblock  %} 


Devuelve  una  URL  absoluta  (Es  decir,  una  URL  sin  la  parte  del  dominio)  que  coincide 
con  una  determinada  vista,  incluyendo  sus  parametros  opcionales.  De  esta  forma  se 
posibilita  realizar  enlaces  sin  violar  el  principio  DRY,  codiflcando  las  direcciones  en 
las  plantillas: 

{%  url  'algun-nombre-de-url'  vl  v2  %} 

El  primer  argumento  es  el  nombre  del  patron  URL  o name.  El  resto  de  parametros 
son  opcionales  y deben  ir  separados  con  comas,  convirtiendose  en  parametros 
posicionales  o por  nombre  que  se  incluiran  en  la  URL.  Deben  estar  presentes  todos 
los  argumentos  que  se  hayan  delinido  como  obligatorios  en  el  URLconf.  No  es 
posible  mezclar  argumentos  posicionales  y argumentos. 

Por  ejemplo,  supongamos  que  tenemos  una  vista,  VistaDetallesCliente,  y que  en  el 
URLconf  se  la  indica  que  acepta  un  parametro,  el  identificador  del  cliente.  La  linea 
del  URL  podria  ser  algo  asi: 

url(r’Acliente/(?P<pk>[0-9]+)/$’,  VistaDetallesCliente. as_view(), 

_name=’detalles-cliente’), 

Si  este  URLconf  fuera  incluido  en  el  URLconf  del  proyecto  bajo  un  directorio, 
como  en  este  ejemplo: 

('Aclientes/',  include('project_name.app_name.urls')) 

Podriamos  crear  un  enlace  a esta  vista,  en  nuestra  plantilla,  con  la  siguiente 
etiqueta: 

{%  url  'detalles-cliente'  cliente. id  %} 

La  salida  de  esta  etiqueta  sera  /clientes/ cliente/ 123/. 


® Advertencia:  No  olvides  poner  comillas  alrededor  del  name  del  patron,  o el  valor 
sera  interpretado  como  el  contexto  de  una  variable. 


url 
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Si  solo  quieres  extraer  la  URL  sin  mostrarla,  puedes  usar  una  llamada  un  poco 
diferente: 

{%  url  ’algun-nombre_patron’  arg  arg2  as  the_url  %} 

<a  href="  { the_url  }}">Estoy  enlazando  a the_url  }}</a> 

El  alcance  de  la  variable  creada  por  la  sintaxis  as  var  es  el  {%  block  %}  en  el  cual  la 
etiqueta  {%  url  %}  aparece. 

Si  quieres  extraer  el  namespaced  de  una  URL,  especifica  la  ruta  completa  a name 
asi: 

{%  url  'miaplicacion:nombre-uri'  %} 

verbatim 

Detiene  el  motor  de  plantillas  que  renderiza  el  contenido  de  esta  etiqueta  de  bloque. 

Un  uso  muy  comun  es  para  permitir  que  Javascript  y la  capa  de  plantillas  no 
colisiones  con  la  sintaxis  de  Django.  Por  ejemplo: 

{%  verbatim  %} 

{{if  dying}}Still  alive. {{/if}} 

{%  endverbatim  %} 

Tambien  se  puede  11am ar  especificamente  a una  etiqueta  de  cierre  {%  endverbatim 
%}  como  parte  del  contenido  no  renderizado. 

{%  verbatim  myblock  %} 

Evita  la  renderizacion  a traves  de  {%  verbatim  %}{%  endverbatim  % block. 

{%  endverbatim  myblock  %} 

widthratio 

Esta  etiqueta  es  util  para  presentar  graficos  de  barras  y similares.  Calcula  la 
proportion  entre  un  valor  dado  y un  maximo  predefinido,  y luego  multiplica  ese 
cociente  por  una  constante. 

Veamos  un  ejemplo: 


<img  src="bar.png"  alt="Bar" 

height="10"  width="{%  widthratio  this_valor  max_valor  max_width  %}"  /> 

Si  este  valor  vale  175  y max_valor  es  200,  la  imagen  resultante  tendra  un  ancho  de 
88  pixels  (porque  175/200  = 0.875  y 0.875  * 100  = 87.5,  que  se  redondea  a 88). 

En  algunos  casos  es  necesario  capturar  el  valor  del  resultado  de  widthratio  en  una 
variable. 

Puede  ser  util  en  instancias,  en  blocktrans  tal  como: 

{%  widthratio  this_valor  max_valor  max_width  as  width  %} 

{%  blocktrans  %}The  width  is:  {{ width  }}{%  endblocktrans  %} 

with 

Cachea  una  variable  complicada  bajo  un  nombre  mas  simple.  Esto  es  util  al  acceder  a 
un  metodo  “costoso”  (e.g.,  uno  que  ‘golpea’  la  base  de  datos)  varias  veces. 

Por  ejemplo: 


{%  with  total=business. employees. count  %} 
{{ total }}  employee  total|pluralize  }} 
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{%  endwith  %} 

La  variable  poblada  (en  el  ejemplo  anterior,  total)  esta  unicamente  disponible 
entre  las  etiquetas  {%  with  %}  y {%  endwith  %}. 

Puedes  asignar  mas  de  una  variable  al  contexto: 

{%  with  alpha=l  beta=2  %} 

{%  endwith  %} 

Filtros  predefinidos 

add 

Agrega  el  argumento  al  valor. 

Ejemplo: 

{{ valor|add:"2" }} 

Si  el  valor  es  4,  la  salida  sera  6. 

addslashes 

Anade  barras  invertidas  antes  de  las  comillas,  ya  sean  simples  o dobles.  Es  util  para 
pasar  cadenas  de  texto  como  javascript,  o para  escapar  cadenas  en  CVS  por  ejemplo: 

{{ valoijaddslashes }} 

Si  el  valor  es  "I'm  using  Django",  la  salida  sera:  "IVm  using  Django" 

capfirst 

Pasa  a mayusculas  la  primera  letra  de  la  primera  palabra.  Si  el  primer  caracter  no  es 
una  letra  el  filtro  no  tiene  efectos. 

Por  ejemplo: 

{{valor|capfirst}} 

Si  el  valor  es  "django",  la  salida  sea  "Django". 

center 

Centra  el  texto  en  un  campo  de  la  anchura  indicada. 

Por  ejemplo: 

"{{ valor|center:"15" }}" 

Si  valor  es  "Django",  la  salida  sera  " Django  ". 
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cut 

Elimina  todos  los  valores  de  los  argumentos  de  la  cadena  dada. 

Por  ejemplo: 

{{ valor|cut:"  " }} 

Si  el  valor" es  " "Cadena  con  espacios",  la  salida  sera  "Cadenaconespacioss". 

date 

Formatea  una  fecha  de  acuerdo  al  formato  indicado  en  la  cadena  de  texto  (Se  usa  el 
mismo  formato  que  con  la  etiqueta  now). 

Ejemplo: 

{{ valor|date:"F  j,  Y" }} 


Formato 

Description 

Salida 

a 

'a.m.'  o 'p.m.'. 

’a.m.’  o ’p.m. 

A 

'AM'  o ’PM’. 

'AM' 

b 

El  nombre  del  mes,  en  forma  de  abreviatura  de  tres 
letras  minusculas. 

’jan' 

d 

Dla  del  mes,  dos  dlgitos  que  incluyen  rellenando  con 
cero  por  la  izquierda  si  fuera  necesario. 

’Of  a '31' 

D 

Dla  de  la  semana,  en  forma  de  abreviatura  de  tres 
letras. 

’Fri' 

f 

La  hora,  en  formato  de  12  horas  y minutos,  omitiendo 
los  minutos  si  estos  son  cero. 

T,  '1:30' 

F 

El  mes,  en  forma  de  texto 

'January' 

g 

La  hora,  en  formato  de  12  horas,  sin  rellenar  por  la 
izquierda  con  ceros. 

T a '12' 

G 

La  hora,  en  formato  de  24  horas,  sin  rellenar  por  la 
izquierda  con  ceros. 

'0'  a '23' 

h 

La  hora,  en  formato  de  12  horas. 

'01'  a'12' 

H 

La  hora,  en  formato  de  24  horas. 

'00'  a '23' 

i 

Minutos. 

'00'  a '59' 

j 

El  dla  del  mes,  sin  rellenar  por  la  izquierda  con  ceros. 

T a '31' 

1 

El  nombre  del  dla  de  la  semana. 

'Friday' 

F 

Booleano  que  indica  si  el  ano  es  bisiesto. 

True  o False 

m 

El  dla  del  mes,  rellenando  por  la  izquierda  con  ceros 
si  fuera  necesario. 

'01'  a'12' 

M 

Nombre  del  mes,  abreviado  en  forma  de  abreviatura 
de  tres  letras. 

’Jan' 

n 

El  mes,  sin  rellenar  con  ceros 

’1'  a'12' 

N 

La  abreviatura  del  mes  siguiendo  el  estilo  de  la 
Associated  Press. 

’Jan.',  ’Feb.'  , 
’March',  'May' 

0 

Diferencia  con  respecto  al  tiempo  medio  de 
Grennwich  [Greenwich Mean  Time  - GMT) 

'+0200' 

P 

La  hora,  en  formato  de  12  horas,  mas  los  minutos, 
recto  si  estos  son  cero  y con  la  indication  a.m. /p.m. 

'1  a.m.',  1:30 

p.m.'  , 'midnight', 
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Ademas,  se  usaran  las  cadenas  de  texto  especiales 
'midnight'  y 'noon'  para  la  medianoche  y el  mediodia 
respectivamente. 

'noon'  , '12:30 

p.m.' 

r 

La  fecha  en  formato  RFC  822. 

'Thu,  21  Dec  2000 
16:01:07  +0200' 

s 

Los  segundos,  rellenos  con  ceros  por  la  izquierda  de 
ser  necesario. 

'00'  a '59' 

S 

El  sufijo  ingles  para  el  dia  del  mes  (dos  caracteres). 

’sf,  ’nd’,  Yd'  o Yh' 

t 

Numero  de  dias  del  mes. 

28  a31 

T 

Zona  horaria 

'EST',  'MDT' 

w 

Dia  de  la  semana,  en  forma  de  digito. 

'O'  (Domingo)  a 
'6'  (Sabado) 

W 

Semana  del  ano,  siguiente  la  norma  ISO-8601,  con  la 
semana  empezando  el  lunes. 

1,23 

y 

Ano,  con  dos  digitos. 

'99' 

Y 

Ano,  con  cuatro  digitos. 

’1999' 

z 

Dia  del  ano 

0 a 365 

Z 

Desfase  de  la  zona  horaria,  en  segundos.  El 
desplazamiento  siempre  es  negativo  para  las  zonas  al 
oeste  del  meridiano  de  Greenwich,  y positivo  para  las 
zonas  que  estan  al  este. 

-43200  a 43200 

Tabla  F-5  Muestra  las  cadenas  de  formato  que  se pueden  utilizar. 


Por  ejemplo: 

{{ valor|date:"D  d M Y" }} 

Si  el  valor  es  un  objeto  datetime  (e.g.,  el  resultado  de  datetime. datetime.nowO),  la 
salida  sera  la  cadena  'Wed  09  Jan  2008'. 

Asumiendo  que  USE_L10N  como  True  y LANGUAGE_CODE  sea,  por  ejemplo, 
"es",  luego: 

{{ valor|date:"SHORT_DATE_FORMAT" }} 

La  salida  sera  la  cadena  "09/01/2008"  (en  el  formato  especifico  para  el  local  es 
usando  "SHORT_DATE_FORMAT"). 

default 

Si  el  valor  evaluado  es  False,  usa  el  valor  definido  como  predeterminado  o default. 

Por  ejemplo: 

{{ valor|default:"nada" }} 

Si  el  valor  es  " " (una  cadena  vacia),  la  salida  sera  nada. 

default_if_none 

Si  (y  unicamente  si)  el  valor  es  None,  se  usa  el  valor  del  argumento  en  su  lugar. 

Observa  que  si  le  pasas  una  cadena  vacia,  el  valor  predeterminado  no  sera  usado. 
Usa  el  fitro  default  si  quieres  tratar  con  cadena  vacias. 
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Por  ejemplo: 

{{ valor|default_if_none:"nada" }} 

Si  valor  es  None,  la  salida  sera  una  cadena  "nada". 

dictsort 

Acepta  una  lista  de  diccionarios  y devuelve  una  lista  ordenada  segun  la  propiedad 
indicada  en  el  argumento. 

Por  ejemplo: 

{{valor  |dictsort:"nombre" }} 

Si  el  valor  es: 

[ 

{’nombre’:  ’zed’,  ’edad’:  19}, 

{’nombre’:  ’amy’,  ’edad’:  22}, 

{’nombre’:  ’joe’,  ’edad’:  31}, 

] 


La  salida  sera: 


[ 

{’nombre’:  ’amy’,  ’edad’:  22}, 
{’nombre’:  ’joe’,  ’edad’:  31}, 
{’nombre’:  ’zed’,  ’edad’:  19}, 

] 


Puedes  hacer  cosas  mas  complicadas  como: 

{%  for  libro  in  libros|dictsort:"autor.edad"  %} 

{{ libro.titulo }}  ({{ libro. autor. nombre  }}) 

{%  endfor  %} 

Si  libros  es: 


[ 

{’titulo’:  ’1984’,  ’autor’:  {’nombre’:  ’George’,  ’edad’:  45}}, 
{’titulo’:  ’Timequake’,  ’autor’:  {’nombre’:  ’Kurt’,  ’edad’:  75}}, 
{’titulo’:  ’Alice’,  ’autor’:  {’nombre’:  ’Lewis’,  ’edad’:  33}}, 

] 

La  salida  sera: 


Alice  (Lewis) 
1984  (George) 
Timequake  (Kurt) 
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dictsortreversed 

Acepta  una  lista  de  diccionarios  y devuelve  una  lista  ordenada  de  forma  descendente 
segun  la  propiedad  indicada  en  el  argumento.  Trabaja  de  forma  parecida  al  anterior 
filtro,  pero  retorna  el  valor  en  orden  inverso. 

Por  ejemplo: 

{{ lista| dictsortreversed: "foo" }} 

divisibleby 

Devuelve  True  si  el  valor  pasado  es  divisible  por  el  argumento. 

Por  ejemplo: 

{{ valor|divisibleby:"3" }} 

Si  el  valor  es  21,  la  salida  sera  True. 

escape 

Escapea  una  cadena  en  HTML.  Concretamente  realiza  los  siguientes  remplazos: 

■ < es  convertido  a &lt; 

■ > es  convertido  a &gt; 

■ ' (comillas  simples)  es  convertido  a &#39; 

■ " (comillas  dobles)  es  convertido  a &quot; 

■ & es  convertido  a &amp; 

El  escape  es  unicamente  aplicado  en  la  salida  de  la  cadena,  asi  que  no  importa 
donde  se  encadenen  la  serie  de  filtros  usando  escape:  este  siempre  sera  aplicado 
como  al  ultimo  filtro.  Si  quieres  que  el  escape  se  aplique  inmediatamente,  utiliza  el 
filtro  force_escape. 

Aplicar  escape  a una  variable  que  normalmente  esta  auto-escapeada,  da  como 
resultado  que  el  escapeo  se  aplique  una  sola  vez.  Por  lo  que  es  seguro  usar  esta 
funcion  incluso  en  ambientes  de  auto -escape.  Si  quieres  pasar  multiples  escapes  usa 
el  filtro  force_escape 

Por  ejemplo,  puedes  aplicar  escape  a campos  cuando  la  etiqueta  autoescape  esta 
desactivada  o en  of: 

{%  autoescape  off  %} 

{{ titulo|escape  }} 

{%  endautoescape  %} 

escapejs 

Escapa  caracteres  para  usar  en  cadenas  Javascript.  Esta  no  marca  las  cadenas  como 
seguras  para  usar  en  HTML,  pero  las  protege  de  errores  de  sintaxis  cuando  se  usan 
plantillas  generadas  por  JavaScript/JSON. 

Por  ejemplo: 

{{ valor|escapejs }} 
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Si  valor  es  "testing\r\njavascript  Vstring"  <b>escaping</b>",  la  salida  sera 
"testingWuOOODWuOOOAjavascript  Wu0027string\\u0022  Wu003Cb 
Wu003Eescaping\\u003C/b\\u003E". 

filesizeformat 

Representa  un  valor,  interpretandolo  como  si  fuera  el  tamano  de  un  fichero  y 
“humanizando”  el  resultado,  de  forma  que  sea  facil  de  leer.  Por  ejemplo,  las  salidas 
podrianser '13  KB',  '4.1  MB',  '102  bytes',  etc. 

Por  ejemplo: 

{{ valor|filesizeformat }} 

Si  valor  es  123456789,1a  salida  sera  117.7  MB. 

Tamano  de  archivos  y unidades  SI 

Estrictamente  hablando  filesizeformat  no  se  ajusta  al  Sistema  Internacional  de 
Unidades  (International  System  of  Units)  que  recomiende  usar  KiB,  MiB,  GiB,  cuando 
el  tamano  de  los  bytes  se  calcula  en  torno  a 1024(como  en  este  caso).  En  lugar  de  eso, 
Django  usa  tradicionalmente  nombres  de  unidades  (KB,  MB,  GB,  etc.) 
correspondiendo  a los  nombres  que  se  utilizan  mas  comunmente. 

first 

Devuelve  el  primer  elemento  de  una  lista. 

Por  ejemplo: 

{{ valor|first }} 

Si  el  valor  esta  en  la  lista  ['a',  'b',  'c'],  la  salida  sera 'a'. 

floatformat 

Si  se  usa  sin  argumento,  redondea  un  numero  en  coma  flotante  a un  unico  digito 
decimal  (pero  solo  si  hay  una  parte  decimal  que  mostrar),  por  ejemplo: 


Valor  Plantilla  Salida 


34.23234  {{ valor|floatformat }}  34.2 

34.00000  {{ valorjfloatformat }}  34 

34.26000  {{ valorjfloatformat }}  34.3 

Si  se  utiliza  un  argumento  numerico,  floatformat  redondea  a ese  numero  tantos 
lugares  como  decimales  definidos,  por  ejemplo: 


Valor  Plantilla  Salida 


34.23234  {{ valor|floatformat:3 }}  34.232 

34.00000  {{ valorjfloatformat:3 }}  34.000 

34.26000  {{ valorjfloatformat:3 }}  34.260 

Particularmente  util  al  pasarselo  al  0 (cero)  como  el  argumento  que  redondea  el 
numero  flotante,  al  valor  entero  mas  cercano. 
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Valor 

Plantilla 

Salida 

34.23234 

{{ valor|floatformat: "0" }} 

34 

34.00000 

{{valor floatformat: "0" }} 

34 

39.56000 

{{valor floatformat: "0" }} 

40 

Si  el  argumento  pasado  a floatformat  es  negativo,  redondeara  a ese  numero  de 
decimales,  pero  solo  si  el  numero  tiene  parte  decimal.  Por  ejemplo: 

Valor 

Plantilla 

Salida 

34.23234 

{{ valor|floatformat:"-3" }} 

34.232 

34.00000 

{{ valorjfloatformat:"-3" }} 

34 

34.26000 

{{valor floatformat: "-3" }} 

34.260 

Usar  floatformat  sin  argumentos  es  equivalente  a usar  floatformat  con  el 
argumento  de  -1. 

force_escape 

Aplica  escapeo  HTML  a la  cadena  (consulta  el  filtro  escape  para  mas  detalles).  Este 
filtro  es  aplicado  inmediatamente  y devuelve  una  nueva  cadena  escapada.  Es  util  en 
raros  casos,  por  ejemplo  cuando  es  necesario  el  uso  de  multiples  escapeos  o cuando 
es  necesario  aplicar  otro  filtro  al  resultado  escapado.  Normalmente  se  usa  el  filtro 
escape. 

Por  ejemplo,  si  quieres  atrapara  los  elemento  HTML  <p>  creados  por  el  filtro 
tfllter : linebreaks. 

{%  autoescape  off  %} 

{{ cuerpo|linebreaks|force_escape }} 

{%  endautoescape  %} 

get_digit 

Dado  un  numero,  devuelve  el  digito  que  este  en  la  position  indicada,  siendo  1 el 
digito  mas  a la  derecha.  En  caso  de  que  la  entrada  sea  invalida,  devolvera  el  valor 
original  (Si  la  entrada  o el  argumento  no  fueran  enteros,  o si  el  argumento  fuera 
inferior  a 1).  Si  la  entrada  es  correcta,  la  salida  siempre  sera  un  entero. 

Por  ejemplo: 

{{ valor|get_digit:"2" }} 

Si  valor  es  123456789,  la  salida  sera  8. 

iriencode 


Convierte  un  IRI  (Identificador  Internacional  de  Recursos  o Internationalized 
Resource  Identifier)  a una  cadena  que  es  conveniente  para  incluir  en  una  URL.  Esto 
es  necesario  su  estan  tratando  de  usar  cadenas  que  contienen  caracteres  que  no  son 
ASCII  en  una  URL. 

Es  seguro  usar  este  filtro  en  una  cadena  que  ha  pasado  por  un  filtro  urlencode. 

Por  ejemplo: 

{{ valor|iriencode  }} 
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Si  valor  es  "?test=l&me=2",  la  salida  sera  "?test=l&amp;me=2". 

join 

Concatena  todos  los  elementos  de  una  lista  para  formar  una  cadena  de  texto,  usando 
como  separador  el  texto  que  se  le  pasa  como  argumento.  Es  equivalente  a la  llamada 
en  Python  str.join(list) 

Por  ejemplo: 

{{  valor|join:"  // " }} 

Si  valor  es  la  lista  ['a',  'b',  'c'],  la  salida  sera  la  cadena:  "a  //  b //  c". 

last 

Devuelve  el  ultimo  item  de  una  lista. 

Por  ejemplo: 

{{ valor|last }} 

Si  valor  es  la  lista  ['a',  'b\  'c',  'd'j,  la  salida  sera  la  cadena  "d". 

length 

Devuelve  la  longitud  del  valor.  Funciona  tanto  en  listas  como  en  cadenas. 

Por  ejemplo: 

{{ valor|length }} 

Si  el  valor  es  ['a',  'b',  'c',  'd'j  o "abed",  la  salida  sera  4. 

El  filtro  devuelve  0 cuando  las  variables  no  estan  definidas. 

length_is 

Devuelve  el  valor  True  si  la  longitud  de  la  entrada  coincide  con  el  argumento 
suministrado,  o de  lo  contrario  False. 

Por  ejemplo: 

{{ valor|length_is:"4" }} 

Si  el  valor  es  ['a',  'b\  'c',  'd'j  o "abed",  la  salida  sera  True. 

linebreaks 

Remplaza  saltos  de  linea  en  texto  piano  con  los  apropiados  formatos  en  E1TML;  una 
simple  nueva  linea  se  convierte  en  un  sal  to  de  linea  en  E1TML  (<br  />)  y una  nueva 
linea  seguida  de  una  linea  en  bianco  se  convierte  en  un  parrafo  (</p>). 


Por  ejemplo: 
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{{ valor|linebreaks }} 

Si  el  valor  es  Joel\nes  un  slug,  la  salida  sera  <p>Joel<br  />es  un  slug</p>. 

linebreaksbr 

Convierte  todos  los  saltos  de  linea  en  etiquetas  <br  />. 

Por  ejemplo: 

{{ valor|linebreaksbr }} 

Si  el  valor  es  Joel\nes  un  slug,  la  salida  sera  Joekbr  />es  un  slug. 

linenumbers 

Muestra  el  texto  de  la  entrada  con  numeros  de  linea. 

Por  ejemplo: 

{{ valor|linenumbers }} 

Si  el  valor  es: 

uno 

dos 

tres 

La  salida  sera: 

1.  uno 

2.  dos 

3.  tres 

ljust 

Justifica  el  texto  de  la  entrada  a la  izquierda  utilizando  la  anchura  indicada. 
Argumento:  tamano  de  campo 
Por  ejemplo: 

{{ valor|ljust:"10" }} 

Si  el  valor  is  Django,  la  salida  sera  "Django  " . 

lower 

Convierte  el  texto  de  la  entrada  dada,  a letras  en  minusculas 
Por  ejemplo: 

{{ valoijlower }} 
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Si  el  valor  es  Sigo  ENOJADO  con  Yoko,  la  salida  sera  sigo  enojado  con  yoko. 

make_list 

Devuelve  la  entrada  en  forma  de  lista.  Si  la  entrada  es  un  numero  entero,  se  devuelve 
una  lista  de  digitos.  Si  es  una  cadena  de  texto,  se  devuelve  una  lista  de  caracteres. 

Por  ejemplo: 

{{ valor|make_list }} 

Si  el  valor  es  la  cadena  "Joel",  la  salida  sera  la  lista:  [T,  'o',  'e',  T].  Si  el  valor  es  123, 
la  salida  sera  la  lista:  [T,  '2',  '3'] 

phone2numeric 

Convierte  un  numero  de  telefono  (que  incluso  puede  contener  letras)  a su  forma 
numerica  equivalente. 

La  entrada  no  tiene  porque  ser  un  numero  de  telefono  valido.  El  filtro  convertira 
alegremente  cualquier  texto  que  se  le  pase. 

Por  ejemplo: 

{{ valor|phone2numeric }} 

Si  el  valor  es  800-COLLECT,  la  salida  sera:  800-2655328. 

pluralize 

Retorno  el  sufijo  para  formar  el  plural  de  cualquier  palabra,  si  el  valor  es  mayor  que 
uno.  Por  defecto  el  sufijo  es  's'. 

Ejemplo: 

Tu  tienes  {{  numjriensajes  }}  mensaje  {{  num_mensajes|pluralize  }}. 

Si  num_mensajes  es  1,  la  salida  sera  Tu  tienes  1 mensaje.  Si  num_mensajes  es  2,  la 
salida  sera  Tu  tienes  2 mensajes. 

Para  aquellas  palabras  que  requieran  otro  sufijo  para  formar  el  plural,  podemos 
usar  una  sintaxis  alternativa  en  la  que  indicamos  el  sufijo  que  queramos  con  un 
argumento. 

Ejemplo: 

Hay  registrados  {{  num_autores  }}  autor{{  num_autores|pluralize:"es" }}. 

Para  aquellas  palabras  que  forman  el  plural  de  forma  mas  compleja  que  con  un 
simple  sufijo,  hay  disponible  una  opcion,  que  permite  indicar  las  formas  en  singular  y 
en  plural,  separandolas  con  una  coma. 

Ejemplo: 

Tu  tienes{{  num_cherries  }}  cherr{{  num_cherries|pluralize:"y,ies" }}. 

Usa  la  etiqueta  blocktrans  para  pluralizar  cadenas  traducidas. 
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pprint 

Un  contenedor  que  permite  llamar  a la  funcion  de  Python  pprint. pprint.  Se  usa  sobre 
todo  para  tareas  de  depurado  de  errores. 

Ejemplo: 

{{ objeto|pprint }} 

random 

Devuelve  un  elemento  elegido  al  azar  de  la  lista. 

Por  ejemplo: 

{{ valor|random  }} 

Si  el  valor  es  la  lista  ['a',  'b',  'c',  'd'],  la  salida  podria  ser:  "b". 

rjust 

Justifica  el  texto  de  la  entrada  a la  derecha  utilizando  la  anchura  indicada. 
Argumento:  El  tamano  del  campo. 

Por  ejemplo: 

"{{ valor|rjust:"10" }}" 

Si  el  valor  es  Django,  la  salida  sera  " Django " . 

safe 

Marca  una  cadena  como  no  requerida  para  escapeo  antes  de  la  salida  en  E1TML. 
Cuando  el  autoescape  esta  en  of,  este  filtro  no  tiene  efecto. 


Nota:  Si  estas  encadenando  flltros,  un  filtro  aplicado  despues  de  safe  puede  hacer 
el  contenido  inseguro  otra  vez.  Por  ejemplo,  el  siguiente  codigo  imprime  las  variables 
como  si  no  estuvieran  escapadas: 


{{ varible|safe|escape }} 


Aplica  el  filtro  safe  a cada  elemento  de  una  secuencia.  Util  en  conjunto  con  otros 
filtros  que  operan  en  secuencia,  tal  como  el  filtro  join. 

Por  ejemplo: 

{{ alguna_lista|safeseq|join:", " }} 

No  se  puede  usar  el  filtro  safe  directamente  en  este  caso,  es  necesario  convertir  la 
variable  en  una  cadena,  en  vez  de  trabajar  con  lo  los  elementos  individuales  de  la 
secuencia. 
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slice 

Devuelve  una  seccion  de  la  lista. 

Usa  la  misma  sintaxis  que  se  usa  en  Python  para  seccionar  una  lista.  Vease: 
http://www.diveintopython3.net/native-datatypes.html#slicinglists  para  una  rapida 
introduccion. 

Ejemplo: 

{{ una_lista|slice:":2" }} 

Si  una_lista  es  ['a',  'b',  'c'],  la  salida  sera:  ['a',  'b']. 

slugify 

Convierte  a ASCCI.  Convierte  el  texto  a minusculas,  elimina  los  caracteres  que  no 
formen  palabras  (caracteres  alfanumericos  y caracter  subrayado),  y convierte  los 
espacios  en  guiones. 

Tambien  elimina  los  espacios  que  hubiera  al  principio  y al  final  del  texto. 

Por  ejemplo: 

{{ valor|slugify }} 

Si  el  valor  es  "Joel  es  un  slug",  la  salida  sera  "joel-es-un-slug". 

stringformat 

Formatea  el  valor  de  entrada  de  acuerdo  a lo  especificado  en  el  formato  que  se  le  pasa 
como  parametro.  La  sintaxis  a utilizar  es  identica  a la  de  Python,  con  la  excepcion  de 
que  el  caracter  “%”  se  omite. 

Puedes  consultar  las  opciones  de  formateo  de  cadenas  de  Python:  en 
http://docs.python.Org/library/stdtypes.html#string-formatting-operations  para  mas 
detalles. 

Por  ejemplo: 

{{ valor|stringformat:"E" }} 

Si  el  valor  es  10,  la  salida  sera  1.000000E+01. 

striptags 


Place  todo  los  posible  por  eliminar  todas  las  etiquetas  [XjElTML. 

Por  ejemplo: 

{{ valor|striptags }} 

Si  el  valor  es  "<b>Joel</b>  <button>es</button>  un  <span>slug</span>",  la  salida 
sera:  "Joel  es  un  slug". 


No  se  garantiza  que  sea  seguro. 
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Nota  que  striptags  no  ofrece  ninguna  garantia  acerca  de  la  salida  segura  en  HTML, 
en  particular  con  entradas  no  validas  de  HTML.  Por  lo  que  NUNCA  apliques  el  filtro 
safe  a la  salida  de  striptags.  Si  estas  buscando  algo  mas  robusto  usa  la  libreria  Python 
bleach,  en  especial  el  metodo  clean . 

time 

Formateas  una  fecha  de  acuerdo  al  formato  dado. 

El  formato  puede  ser  predefinido  con  TIME_FORMAT,  o con  un  formato 
personalizado,  al  igual  que  el  filtro  date.  Nota  que  el  formato  predefinido  es 
dependiente  del  valor  local. 

Por  ejemplo: 

{{ valor|time:"H:i" }} 

Si  el  valor  es  equivalente  a date  time,  date  time. now (),  la  salida  sera  la  cadena 
"01:23". 

Otro  ejemplo: 

Asumiendo  que  USE_L10N  sea  True  y LANGUAGE_CODE  sea,  por  ejemplo  "de", 
entonces  para: 

{{ valor|time:"TIME_FORMAT" }} 

La  salida  sera  la  cadena  "01:23:00"  (El  formato  especifico  "TIME_FORMAT"  para 
el  valor  local  de  en  Django  es  "H:i:s") 

El  filtro  time  unicamente  acepta  parametros  en  el  formato  de  cadenas  o strings 
que  se  relacionen  con  la  hora,  no  con  la  fecha  (por  obvias  razones).  Si  necesitas  un 
formato  para  valores  date  usa  el  filtro  date  en  su  lugar. 

Hay  una  exception  a la  regia  anterior:  Cuando  se  pasa  un  valor  datetime  con 
information  adjunta  timezone,  el  filtro  time  acepta  el  formato  timezone 
espetificamente  los  formatos  'e',  'O' , 'T'  y 'Z'. 

Cuando  se  usa  sin  un  formato  de  cadenas: 

{{ valor|time  }} 

El  formato  definido  con  TIME_FORMAT  sera  usado  si  se  aplica  la  localization. 

timesince 

Formatea  una  fecha  como  un  intervalo  de  tiempo  (por  ejemplo,  “4  dias,  6 horas”). 

Acepta  un  argumento  opcional,  que  es  una  variable  con  la  fecha  a usar  como 
punto  de  referencia  para  calcular  el  intervalo  (Si  no  se  especifica,  la  referencia  es  el 
momento  actual).  Por  ejemplo,  si  blog_date  es  una  fecha  con  valor  igual  a la 
medianoche  del  1 de  junio  de  2006,  y comment_date  es  una  fecha  con  valor  las  08:00 
horas  del  dia  1 de  junio  de  2006,  entonces  lo  siguiente  devolvera  “8  horas”. 

{{  blog_date|timesince:comment_date }} 

Los  minutos  son  la  unidad  mas  pequena  usada  y “0  minutos”  sera  devuelto  por 
cualquier  fecha  que  este  en  el  futuro  con  relation  al  punto  de  comparacion. 
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timeuntil 

Es  similar  a timesince,  excepto  en  que  mide  el  tiempo  desde  la  fecha  de  referencia 
hasta  la  fecha  dada.  Por  ejemplo,  si  hoy  es  1 de  junio  de  2006  y conference_date  es 
una  fecha  cuyo  valor  es  igual  al  29  de  junio  de  2006,  entonces  {{ 
conference_date|timeuntil:from_date  }}  devolvera  “4  semanas”. 

Acepta  un  argumento  opcional,  que  es  una  variable  con  la  fecha  a usar  como 
punto  de  referencia  para  calcular  el  intervalo,  si  se  quiere  usar  otra  distinta  del 
momento  actual.  Si  from_date  apunta  al  22  de  junio  de  2006,  entonces  {{ 
conference_date|timeuntil:from_date  }}  devolvera  “1  semana”. 

{{ conference_date|timeuntil:from_date }} 

Los  minutos  son  la  unidad  mas  pequena  usada  y “0  minutos”  sera  devuelto  por 
cualquier  fecha  que  este  en  el  futuro  con  relation  al  punto  de  comparacion. 

title 

Convierte  una  cadena  de  texto  en  forma  de  titulo,  siguiendo  las  convenciones  del 
idioma  ingles  (todas  las  palabras  con  la  inicial  en  mayuscula). 

Por  ejemplo: 

{{ valor|titulo }} 

Si  el  valor  es  "mi  PRIMER  post",  la  salida  sera  "Mi  primer  Post". 

truncatechars 

Recorta  la  salida  de  una  cadena  de  forma  que  tenga  como  maximo  el  numero  de 
caracteres  que  se  indican  en  el  argumento.  Las  cadenas  truncadas  terminaran  con 
una  secuencia  de  puntos  de  suspension 

Argumento:  El  numero  de  caracteres  a recortar. 

Por  ejemplo: 

{{ valor|truncatechars:9 }} 

Si  el  valor  es  " Joel  es  un  slug" , la  salida  sera  " Joel  e. . . " . 

truncatechars_html 

Parecida  al  filtro  truncatechars,  excepto  que  es  capaz  de  reconocer  las  etiquetas 
HTML  y,  por  tanto,  no  deja  etiquetas  “huerfanas”.  Cualquier  etiqueta  que  se  hubiera 
abierto  antes  del  punto  de  recorte  es  cerrada  por  el  propio  filtro. 

Por  ejemplo: 

{{ valor|truncatechars_html:9 }} 

Si  el  valor  es  "<p>Joel  es  un  slug</p>",  la  salida  sera:  "<p>Joel  i...</p>". 

Las  nuevas  lineas  en  el  contenido  del  HTML  seran  conservadas. 
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truncatewords 

Recorta  la  salida  de  forma  que  tenga  como  maximo  el  numero  de  palabras  que  se 
indican  en  el  argumento. 

Argumento:  El  numero  de  palabras  a recortar  o truncar 
Por  ejemplo: 

{{ valor|truncatewords:2 }} 

Si  el  valor  es  "Joel  es  un  slug",  la  salida  sera:  "Joel  es 
Las  nuevas  lineas  en  la  cadena  seran  removidas. 

truncatewords_html 

Es  similar  a truncatewords,  excepto  que  es  capaz  de  reconocer  las  etiquetas  HTML  y, 
por  tanto,  no  deja  etiquetas  “huerfanas”.  Cualquier  etiqueta  que  se  hubiera  abierto 
antes  del  punto  de  recorte  es  cerrada  por  el  propio  filtro. 

Es  menos  eficiente  que  truncatewords,  asi  que  debe  ser  usado  solamente  si 
sabemos  que  en  la  entrada  va  texto  HTML.Por  ejemplo: 

{{ valor|truncatewords_html:2  }} 

Si  el  valor  es  "<p>Joel  es  un  slug</p>",  la  salida  sera:  "<p>Joel  es  ...</p>". 

Las  nuevas  lineas  en  el  contenido  del  HTML  seran  conservadas. 

upper 

Convierte  una  cadena  o string  a mayusculas. 

Por  ejemplo: 

{{ valor|upper }} 

Si  el  valor  es  “Joel  es  un  slug",  la  salida  sera:  "JOEL  ES  UN  SLUG". 

urlencode 

Escapa  la  entrada  de  forma  que  pueda  ser  utilizado  dentro  de  una  URL. 

Por  ejemplo: 

{{ valor|urlencode }} 

Si  el  valor  es  “http://www.example.org/foo?a=b&c=d”,  la  salida  sera: 
“http%3A//www.example.org/foo%3Fa%3Db%26c%3Dd”. 

Opcionalmente  podemos  pasarle  un  argumento  que  contiene  los  caracteres  que 
no  deben  ser  escapados.  Si  no  se  le  provee,  el  caracter  7 ’ es  asumido  como  seguro. 
Una  cadena  vacia  puede  proveerse  cuando  todos  los  caracteres  deben  ser  escapados. 
Por  ejemplo: 


{{ valor|urlencode:"" }} 
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Si  el  valor  es  “http://www.example.org/”,  la  salida  sera: 
“http%3A%2F%2Fwww.example.org%2F”. 

urlize 

Convierte  URLs  y direcciones  de  email  en  texto  a enlaces  F1TML. 

Esta  plantilla  de  etiqueta  funciona  en  enlaces  que  contienen  prefijos  como  http://, 
https://,  o www..  Por  ejemplo,  http://goo.gl/aialt  sera  convertido,  pero  goo.gl/aialt 
no. 

Tambien  soporta  links,  unicamente  en  el  nivel  superior  de  dominios  (.com,  .edu, 
.gov,  .int,  .mil,  .net,  y .org).  Por  ejemplo  funciona  con  djangoproject.com. 

Por  ejemplo: 

{{ valor[urlize }} 

Si  valor  es  “Check  out  www.djangoproject.com”,  la  salida  sera  “Check  out  <a 
href=”http://www.djangoproiect.com 
rel=”nofollow”>www.djangoproject.com</a>  ” . 

urlizetrunc 

Convierte  las  direcciones  URL  de  un  texto  en  enlaces  al  igual  que  urlize,  recortando  la 
representation  de  la  URL  para  que  el  numero  de  caracteres  sea  como  maximo  el  del 
argumento  suministrado. 

Argumento:  Numero  de  caracteres  que  el  enlace  de  texto  debe  contener 
incluyendo  los  puntos  suspensivos  que  agrega  el  filtro. 


Por  ejemplo: 

{{ valor|urlizetrunc:15 }} 

Si  el  valor  es  “Check  out  www.djangoproject.com”,  la  salida  sera:  “Check  out  <a 
href=”http://www.djangoproject.com”  rel=”nofollow”>www.djangopr...</a>”. 

Al  igual  que  urlize,  solo  se  puede  aplicar  al  texto  piano. 

wordcount 

Devuelve  el  numero  de  palabras  en  la  entrada. 

Por  ejemplo: 

{{ valor|wordcount }} 

Si  el  valor  es  "Joel  es  un  slug" , la  salida  sera  4. 

wordwrap 

Ajusta  la  longitud  del  texto  para  las  lineas  se  adecuen  a la  longitud  especificada  como 
argumento. 

Argumento:  El  numero  de  caracteres  a los  cuales  ajustar  el  texto. 
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Por  ejemplo: 

{{ valor|wordwrap:5 }} 

Si  el  valor  es  Joel  es  un  slug,  la  salida  sera: 

Joel 
is  a 
slug 

yesno 

Dada  una  serie  de  textos  que  se  asocian  a los  valores  de  True,  False  y (opcionalmente) 
None,  devuelve  uno  de  esos  textos  segun  el  valor  de  la  entrada.  Vease  la  siguiente 
tabla: 

Por  ejemplo: 

{{ valor|yesno:"yeah, no, maybe" }} 


Valor 

Argumento 

Salida 

True 

"yeah, no, maybe" 

yeah 

False 

"yeah, no, maybe" 

no 

None 

"yeah, no, maybe" 

maybe 

None 

"yeah, no" 

"no"  (considera  None  como  False  si  no  se  asigna  ningun 

texto  a None. 


Tabla  E6  Ejemplos  del  filtro  yesno 

Filtros  y etiquetas  de  internacionalizacion 


Django  proporciona  una  serie  de  etiquetas  y filtros  que  controlan  cada  aspecto  de  la 
Internacionalizacion  en  las  plantillas.  Permiten  mantener  de  forma  granular  las 
traducciones,  el  formato,  y las  conversiones  de  las  zonas  horarias. 

i!8n 


Esta  libreria  permite  especilicar  el  texto  traducible  en  las  plantillas.  Para  usarla 
asegurate  que  USE_U8N  este  establecido  en  True,  luego  cargala  con  {%  load  il8n  %}. 

llOn 

Esta  libreria  proporciona  control  sobre  los  valores  de  localizacion  en  las  plantillas. 
Unicamente  necesitas  cargar  esta  libreria  usando  {%  load  llOn  %},  pero  necesitas  que 
USE_L10N  a True  de  modo  que  la  localizacion  este  activa  de  forma  predeterminada. 

tz 


Esta  libreria  proporciona  control  sobre  las  conversiones  de  zonas  horario  en  las 
plantillas,  tal  como  llOn,  unicamente  necesitas  cargar  la  libreria  usando  {%  load  tz  %} 
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pero  necesitas  que  USE_TZ  sea  True  de  modo  que  la  conversion  este  activa  de  forma 
predeterminada. 


Otras  etiquetas  y filtros  utiles 

Django  viene  ademas  con  unas  par  de  bibliotecas,  que  permiten  usar  otras  etiquetas, 
que  es  necesario  habilitar  explicitamente  en  INSTALLED_APPS  para  usarlas  en  las 
plantillas  con  la  etiqueta  {%  load  %}. 

dj  ango.  contrib.  humanize 

Un  conjunto  de  filtros  de  plantillas,  utiles  para  darle  un  toque  humano  a los  datos. 

django.contrib.webdesign 

Una  coleccion  de  etiquetas  de  plantilla,  que  pueden  ser  utiles  en  el  diseno  de  sitios 
web,  tal  como  la  generation  de  texto  del  tipo:  Lorem  Ipsum. 

static 

Para  enlazar  los  archivos  estaticos  que  se  guardan  en  STATIC_ROOT  Django  usa  la 
etiqueta  static.  Puedes  usar  esta  etiqueta  de  plantilla  independientemente  de  que 
uses  RequestContext  o no. 

{%  load  static  %} 

<img  src="{%  static  "imagenes/hola.jpg"  %}"  alt="Hola!"  /> 

Puedes  usarla  para  enlazar  y consumir  diferentes  variables  de  contexto,  ademas  de 
los  estandares,  por  ejemplo  asumiendo  que  la  variable  hoja_de_estilo.css  sea  pasada 
a la  plantilla: 


{%  load  static  %} 

<link  rel="stylesheet"  href="{%  static  hoja_de_estilo.css  %}" 
type="text/css"  media-'screen"  /> 


Si  lo  que  quieres  es  recuperar  la  URL  estatica  para  mostrarla,  puedes  usar  una 
llamada  un  poco  diferente: 

{%  load  static  %} 

{%  static  "imagenes/hola.jpg"  as  mifoto  %} 

<img  src="{{  mifoto  }}"></img> 

get_static_prefix 

Es  preferible  que  uses  la  etiqueta  de  plantilla  static,  pero  si  necesitas  tener  un  control 
mas  exacto  sobre  como  y donde  STATIC_URL  es  inyectado  en  la  plantilla,  puedes 
usar  la  etiqueta  de  plantilla:  get_static_prefix: 

{%  load  static  %} 

<img  src="{%  get_static_p refix  %}imagenes/hi.jpg"  alt="Hi!"  /> 
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Existe  una  segunda  forma  de  poder  utilizarla  y asi  evitar  el  procesamiento  extra  si 
necesitas  usar  varias  veces,  multiples  valores: 

{%  load  static  %} 

{%  get_static_prefix  as  STATIC_PREFIX  %} 

<img  src="{{  STATIC_PREFIX  }}imagenes/hi.jpg"  alt-'Hi!"  /> 

<img  src="{{  STATIC_PREFIX  }}imagenes/hi2.jpg"  alt="Hola!"  /> 

get_media_prefix 

Parecida  a la  etiqueta  get_static_prefix,  get_media_prelix  puebla  la  variable  de  la 
plantilla  con  el  prefijo  de  media  MEDIA_URL. 

Por  ejemplo: 

<script  type="text/javascript"  charset="utf-8"> 
var  media_path  = ’{%  get_media_prefix  %}’; 

</script> 


APENDICE  F 


El  utilitario  django-admin 


El  utilitario  de  linea  de  comandos  de  Django,  es  django-admin.py  disenado  para 
realizar  tareas  administrativas.  Este  apendice  explica  sus  multiples  poderes. 

Usualmente  accedes  a django-admin.py  a traves  del  wrapper  del  proyecto 
manage.py,  manage.py  es  creado  automaticamente  en  cada  proyecto  Django  y es  un 
contenedor  liviano  en  torno  a django-admin.py.  Toma  cuidado  de  algunas  cosas  por 
ti  antes  de  delegar  el  trabajo  a django-admin.py: 

■ Pone  el  paquete  de  tu  proyecto  en  sys.path. 

■ Establece  la  variable  de  entorno  DJANGO_SETTINGS_MODULE  para  que 
apunte  al  archivo  settings.py  de  tu  proyecto. 

■ Llama  a django.setupO  para  inicializar  varias  funciones  internas  de  Django. 

El  script  django-admin.py  debe  estar  en  la  ruta  de  tu  sistema  si  instalaste  Django 
mediante  su  utilitario  setup.py.  Si  no  esta  en  tu  ruta,  puedes  encontrarlo  en  site- 
packages/django/bin  dentro  de  tu  instalacion  de  Python.  Considera  establecer  un 
enlace  simbolico  a el  desde  algun  lugar  en  tu  ruta,  como  en  /usr/local/bin. 

Los  usuarios  de  Windows,  que  no  disponen  de  la  funcionalidad  de  los  enlaces 
simbolicos,  pueden  copiar  django-admin.py  a una  ubicacion  que  este  en  su  ruta 
existente  o editar  la  configuracion  del  PATE!  (bajo  Configuracion  > Panel  de  Control  > 
Sistema  > Avanzado  > Entorno)  para  apuntar  a la  ubicacion  de  su  instalacion. 

Generalmente,  cuando  se  trabaja  en  un  proyecto  Django  simple,  es  mas  facil  usar 
manage.py.  Usa  django-admin.py  con  DJANGO_SETTINGS_MODULE  o la  option  de 
linea  de  comando  —settings,  si  necesitas  cambiar  entre  multiples  archivos  de 
configuracion  de  Django. 


Uso 

django-admin.py  <comando>  [opciones] 

O puedes  usar: 

manage.py  <comando>  [opciones] 

Donde  comando  debe  ser  uno  de  los  comandos  listados  en  este  documento  y las 
opciones,  son  opcionales  y pueden  ser  cero  o mas  de  las  listadas  en  este  documento. 

Los  ejemplos  de  linea  de  comandos  a lo  largo  de  este  apendice  usan  django- 
admin.py  para  ser  consistentes,  pero  cada  ejemplo  puede  usar  de  la  misma  forma 
manage.py.  (O  simplemente  django-admin  o manage  sin  la  extencion  .py, 
dependiendo  de  tu  tipo  de  instalacion.) 
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Obtener  ayuda 
django-admin.  py  help 

Ejecuta  django-admin  help  para  mostrar  la  informacion  de  uso  y una  lista  de  todos 
los  comandos  proporcionados  por  cada  aplicacion. 

Ejecuta  django-admin  help  —commands  para  mostrar  una  lista  de  todos  los 
comandos  disponibles. 

Ejecuta  django-admin  help  <command>  para  mostrar  la  description  de  un 
comando  dado  y una  lista  de  las  opciones  disponibles. 

Nombres  de  las  aplicaciones 

Muchos  de  los  subcomandos  toman  una  lista  de  “nombres  de  aplicaciones”.  Un 
nombre  de  una  aplicacion  es  el  nombre  base  del  el  paquete  que  contiene  el  modelo. 
Por  ejemplo,  si  tu  INSTALLED_APPS  contiene  la  cadena  'misitio.blog',  el  nombre  de 
la  aplicacion  es  blog. 

Determinar  la  version 

django-admin.py  version 

Ejecuta  django-admin.py --version  para  mostrar  la  version  actual  de  Django. 

Ejemplos  de  la  salida: 

• 1.7 

• 1.8 

• 1.9 

Mostrar  la  salida  de  depuracion 

Usa  —verbosity  para  especificar  la  cantidad  de  notiflcaciones  e informacion  de 
depuracion  que  django-admin.py  debe  imprimir  en  consola.  Para  mas  informacion 
consulta  la  documentation  de  la  option  —verbosity. 

Subcomandos  Disponibles 

Las  siguientes  secciones  cubren  las  acciones  disponibles. 

check  <appname  appname  ...> 
django-admin  .py  check 

Usa  el  framework  check  para  inspeccionar  el  proyecto  completo  para  detectar 
problemas  comunes. 

El  framework  check  Confirma  que  no  haya  ningun  problema  con  los  modelos 
instalados  o los  registros  en  la  interfaz  administrativa.  Tambien  provee  de 
advertencias  para  detectar  problemas  comunes  de  compatibilidad,  introducidos  al 
actualizar  Django  a una  nueva  version.  Tambien  se  pueden  realizar  chequeos 
personalizados  usando  otras  bibliotecas  y otras  aplicaciones. 
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De  forma  predeterminada,  todas  las  aplicaciones  seran  checadas.  Puedes  checar 
un  conjunto  de  aplicaciones  proporcionando  una  lista,  de  cada  una  de  las 
aplicaciones  como  argumentos: 

python  manage. py  check  auth  admin  myapp 

Si  no  especificas  alguna  aplicacion,  todas  las  aplicaciones  seran  checadas. 

--tag  <tagname> 

El  framework  check  realiza  diferentes  tipos  de  chequeos.  Estos  tipos  de  chequeos 
estan  clasificados  en  diferentes  categorias,  agrupadas  en  etiquetas.  Puedes  usar  estas 
etiquetas  para  restringir  el  chequeo  realizado  a una  categoria  en  especifico.  Por 
ejemplo  para  unicamente  realizar  un  chequeo  de  seguridad  y compatibilidad,  puedes 
ejecutar: 

python  manage. py  check  -tag  security  -tag  compatibility 
-list-tags 

Para  obtener  una  lista  de  todas  las  etiquetas  de  categorias  disponibles,  usa: 

-deploy 

La  opcion  --deploy  activa  una  serie  de  chequeos  adicionales,  que  son  relevantes 
unicamente  en  configuration  de  production. 

Compilemessages 

django-admin.py  compilemessages 

Compila  archivos  .po  creado  s por  makemessages  a archivos  .mo  para  ser  usados  por 
el  soporte  gettext. 

Usa  la  opcion  --locale  (o  su  version  corta  -1)  para  especificar  la  localidad(es)  a 
procesar.  Si  no  la  provees,  todas  las  localidades  seran  procesadas. 

Usa  la  opcion  —exclude  (o  su  version  corta  -x)  para  especificar  la  localidad(es)  a 
excluir  del  procesamiento.  Si  no  la  provees  ninguna  localidad  sera  excluida. 

Ejemplos  de  su  uso: 

django-admin  compilemessages  -locale=pt_BR 
django-admin  compilemessages  -locale=pt_BR  -locale=fr 
django-admin  compilemessages  -I  pt_BR 
django-admin  compilemessages  -I  pt_BR  -I  fr 
django-admin  compilemessages  -exclude=pt_BR 
django-admin  compilemessages  -exclude=pt_BR  -exclude=fr 
django-admin  compilemessages  -x  pt_BR 
django-admin  compilemessages  -x  pt_BR  -x  fr 

createcachetable 

django-admin.py  createcachetable 

Crea  una  tabla  de  cache  llamada  tablename  para  usar  con  el  back-end  de  cache  de  la 
base  de  datos.  Ver  el  capitulo  15  para  mas  information  sobre  la  cache. 
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La  opcion  —database  puede  ser  usada  para  especiflcar  la  base  de  datos  en  la  cual 
se  instalara  la  tabla  de  cache.  Sin  embargo  no  es  necesario  proveer  el  nombre  para  la 
tabla  de  la  cache  a la  opcion  —database.  Django  toma  esta  information  del  archivo  de 
configuracion.  Si  tienes  configuradas  multiples  caches  o multiples  bases  de  datos, 
todas  las  tablas  de  cache  seran  creadas. 

dbshell 

django-admin.py  dbshell 

Corre  el  cliente  de  linea  de  comandos  del  motor  de  base  de  datos  especificado  en  tu 
configuracion  de  DATABASE_ENGINE,  con  los  parametros  de  conexion  especiflcados 
en  la  configuracion  de  DATABASEJUSER,  DATABASE_PASSWORD,  etc. 

■ Para  PostgreSQL,  esto  ejecuta  el  cliente  de  linea  de  comandos  psql . 

■ For  MySQL,  esto  ejecuta  el  cliente  de  linea  de  comandos  mysql. 

■ For  SQLite,  esto  ejecuta  el  cliente  de  linea  de  comandos  sqlite3. 

Este  comando  asume  que  los  programas  estan  en  tu  PATH  de  manera  que  una 
simple  llamada  con  el  nombre  del  programa  (psql,  mysql,  o sqlite3)  encontrara  el 
programa  en  el  lugar  correcto.  No  hay  forma  de  especiflcar  en  forma  manual  la 
localization  del  programa. 

La  opcion  —database  puede  usarse  para  especiflcar  la  base  de  datos  sobre  la  cual 
abrir  el  Shell  de  comandos. 

diffsettings 

django-admin.py  diffsettings 

Muestra  las  diferencias  entre  la  configuracion  actual  y la  configuracion  por  omision 
de  Django. 

Las  configuraciones  que  no  aparecen  en  la  configuracion  por  omision  estan  seguidos 
por"###". 

Por  ejemplo,  la  configuracion  por  omision  no  define  ROOT_URLCONF,  por  lo  que 
si  aparece  ROOT_URLCONF  en  la  salida  de  diffsettings  lo  hace  seguido  de  "###". 

La  opcion  —all  puede  ser  usada  para  mostrar  todas  las  configuraciones,  incluso  si 
tienen  valores  predefinidos  por  Django.  Tales  configuraciones  aparecen  seguidas  del 
prefijo  de  "###". 

Observa  que  la  configuracion  por  omision  de  Django  habita  en 
django.conf.global_settings,  si  alguna  vez  sientes  curiosidad  por  ver  la  lista  completa 
de  valores  por  omision. 

dumpdata  [appname  appname ...] 

django-admin.py  dumpdata 

Dirige  a la  salida  estandar  todos  los  datos  de  la  base  de  datos  asociados  con  la(s) 
aplicacion(es)  nombrada(s). 

Si  no  se  le  provee  el  nombre  de  una  aplicacion,  todas  las  aplicaciones  instaladas 
seran  volcadas. 

La  salida  de  dumpdata  puede  ser  usada  como  entrada  para  loaddata.  Observa 
que  dumpdata  usa  el  manager  predeterminado  en  el  modelo  para  seleccionar  el 
volcado.  Si  estas  usando  un  manager  personalizado  como  el  manejador 
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predeterminado  y si  filtras  algunos  registros  disponibles,  no  todos  los  objetos  seran 
volcados. 

La  opcion  —all  puede  ser  usada  para  especificar  el  manejador  base  que  deberia 
usar  dumpdata  como  manager,  para  volcar  registros  los  cuales  han  sido  filtrados  o 
modificados  por  un  manager  personalizado. 

--format  <fmt> 

--indent  <num> 

Por  omision,  la  base  de  datos  sera  volcada  en  formato  JSON.  Si  quieres  que  la 
salida  este  en  otro  formato,  usa  la  opcion  —format  (ej.:  format=xml).  Puedes 
especificar  cualquier  back-end  de  serializacion  de  Django  (incluyendo  cualquier 
back-end  de  serializacion  especificado  por  el  usuario  mencionado  en  la 
configuration  de  SERIALIZATION_MODULES  setting). 

De  forma  predeterminada  la  salida  de  dumpdata  se  da  en  una  simple  linea.  Que  no 
es  sencilla  de  leer,  puedes  usar  la  opcion  —indent  para  mostrar  la  salida  indentada  de 
acuerdo  a el  numero  de  espacios. 

La  opcion  —exclude  puede  ayudar  a prevenir  que  especificas  aplicaciones  o 
modelos  (especificados  en  el  formato  appJabel.ModelName)  sean  volcadas.  Si 
especificas  un  nombre  de  un  modelo  a dumpdata,  la  salida  del  volcado  sera 
restringida  a ese  modelo,  en  lugar  de  la  aplicacion.  Puedes  mezclar  nombres  de 
aplicaciones  y nombres  de  modelos. 

flush 

django-admin.py  flush 

Remueve  todos  los  datos  de  la  base  de  datos,  esto  significa  que  todos  los  datos  seran 
eliminados  de  la  base  de  datos,  todo  manejador  de  post-sincronizacion  sera 
reejecutado,  y los  datos  iniciales  seran  reinstalados. 

La  opcion  —noinput  puede  proveerse  para  suprimir  todos  los  mensajes  de 
confirmation  de  los  comandos  en  la  terminal  del  usuario. 

La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  a vaciar 
(flush) 


--no-initial-data 


Usa  —no-initial-data  para  evitar  cargar  en  la  instalacion  datos  iniciales. 

inspectdb 

django-admin.py  inspectdb 

Realiza  la  introspection  sobre  las  tablas  de  la  base  de  datos  apuntada  por  la 
configuration  NAME  y envia  un  modulo  de  modelo  de  Django  (un  archivo 
models. py)  a la  salida  estandar. 

Usa  esto  si  tienes  una  base  de  datos  personalizada  con  la  cual  quieres  usar  Django.  El 
script  inspeccionara  la  base  de  datos  y creara  un  modelo  para  cada  tabla  que 
contenga. 

Como  podras  esperar,  los  modelos  creados  tendran  un  atributo  por  cada  campo 
de  la  tabla.  Observa  que  inspectdb  tiene  algunos  casos  especiales  en  los  nombres  de 
campo  resultantes: 
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* Si  inspectdb  no  puede  mapear  un  tipo  de  columna  a un  tipo  de  campo  del 
modelo,  usara  TextField  e insertara  el  comentario  Python  'This  field  type  is  a 
guess.’  junto  al  campo  en  el  modelo  generado. 

■ Si  el  nombre  de  columna  de  la  base  de  datos  es  una  palabra  reservada  de 
Python  ( como  ’pass’,  ’class’,  o ’for’),  inspectdb  agregara  ’_field'  al  nombre  de 
atributo.  Por  ejemplo,  si  una  tabla  tiene  una  columna  ’for’,  el  modelo 
generado  tendra  un  campo  ’for_field’,  con  el  atributo  db_column  establecido 
en  ’for’,  inspectdb  insertara  el  comentario  Python  ’Field  renamed  because  it 
was  a Python  reserved  word.’  junto  al  campo. 

Esta  caracteristica  esta  pensada  como  un  atajo,  no  como  la  generation  de  un 
modelo  definitivo.  Despues  de  ejecutarla,  querras  revisar  los  modelos  generados  para 
personalizarlos.  En  particular,  necesitaras  reordenar  los  modelos  de  manera  tal  que 
las  relaciones  esten  ordenadas  adecuadamente. 

Las  claves  primarias  son  detectadas  automaticamente  durante  la  introspection 
para  PostgreSQL,  MySQL,  y SQLite,  en  cuyo  caso  Django  coloca  primary_key=True 
donde  sea  necesario. 

inspectdb  trabaja  con  PostgreSQL,  MySQL,  y SQLite.  La  detection  de  claves  foraneas 
solo  funciona  en  PostgreSQL  y con  ciertos  tipos  de  tablas  MySQL. 

La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  a 
introspeccionar. 


loaddata  [fixture  fixture ...] 
django-admin.py  loaddata 

Busca  y carga  el  contenido  del  ‘fixture’  nombrado  en  la  base  de  datos. 

La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la 
cual  cargar  los  datos. 

— ignorenonexistent 

La  opcion  —ignorenonexistent  puede  ser  usada  para  ignorar  campos  y modelos  que 
hayan  sido  removidos  desde  que  fixture  fue  generada  originalmente 

-app 

La  opcion  -app  puede  ser  usada  para  especificar  una  sola  aplicacion  donde  buscar 
fixtures  en  lugar  de  buscar  en  todas  las  aplicaciones. 


Que  es  un  “fixture”? 


Un  fixture  es  una  coleccion  de  archivos  que  contienen  los  contenidos  de  la  base  de 
datos  serializados.  Cada  fixture  tiene  un  nombre  unico;  de  todas  formas,  los  archivos 
que  conforman  el  fixture  pueden  estar  distribuidos  en  varios  directorios  y en  varias 
aplicaciones. 

Django  buscara  fixtures  en  tres  ubicaciones: 


1.  En  el  directorio  fixtures  de  cada  aplicacion  instalada. 
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2.  En  todo  directorio  nombrado  en  la  configuration  FIXTURE_DIRS 

3.  En  el  path  literal  nombrado  por  el  fixture 

Django  cargara  todos  los  fixtures  que  encuentre  en  estas  ubicaciones  que 
coincidan  con  los  nombres  de  fixture  dados. 

Si  el  fixture  nombrado  tiene  una  extension  de  archivo,  solo  se  cargaran  fixtures  de 
ese  tipo.  Por  ejemplo  lo  siguiente: 

django-admin.py  loaddata  mydata.json 

Solo  cargara  fixtures  JSON  llamados  mydata.  La  extension  del  fixture  debe 
corresponder  al  nombre  registrado  de  un  serializador  (ej.:  json  o xml). 

Si  omites  la  extension,  Django  buscara  todos  los  tipos  de  fixture  disponibles  para 
un  fixture  coincidente.  Por  ejemplo,  lo  siguiente: 

django-admin.py  loaddata  mydata 

Buscara  todos  los  fixture  de  cualquier  tipo  de  fixture  llamado  mydata.  Si  un 
directorio  de  fixture  contiene  mydata.json,  ese  fixture  sera  cargado  como  un  fixture 
JSON.  De  todas  formas,  si  se  descubren  dos  fixtures  con  el  mismo  nombre  pero 
diferente  tipo  (ej.:  si  se  encuentran  mydata. json  y mydata.xml  en  el  mismo  directorio 
de  fixture),  la  instalacion  de  fixture  sera  abortada,  y todo  dato  instalado  en  la  llamada 
a loaddata  sera  removido  de  la  base  de  datos. 

Los  fixtures  que  son  nombrados  pueden  incluir  como  componentes  directorios. 
Estos  directorios  seran  incluidos  en  la  ruta  de  busqueda.  Por  ejemplo,  lo  siguiente: 

django-admin.py  loaddata  foo/bar/mydata.json 

Buscara  <appname>/fixtures/foo/bar/mydata.json  para  cada  aplicacion  instalada, 
<dirname>/foo/bar/mydata.json  para  cada  directorio  en  FIXTURE_DIRS,  y la  ruta 
literal  foo/bar/mydata.json. 

Observa  que  el  orden  en  que  cada  fixture  es  procesado  es  indefinido.  De  todas 
formas,  todos  los  datos  de  fixture  son  instalados  en  una  unica  transaction,  por  lo  que 
los  datos  en  un  fixture  pueden  referenciar  datos  en  otro  fixture.  Si  el  back-end  de  la 
base  de  datos  admite  restricciones  a nivel  de  registro,  estas  restricciones  seran 
chequeadas  al  final  de  la  transaction. 

El  comando  dumpdata  puede  ser  usado  para  generar  la  entrada  para  loaddata. 

Comprimir  fixtures 

Los  fixtures  pueden  ser  comprimidos  en  formato  zip,  gz,  o bz2.  Por  ejemplo: 
django-admin.py  loaddata  mydata.json 

El  comando  anterior  buscaria  cualesquiera  de:  mydata.json,  mydata.json.zip, 
mydata.json.gz,  o mydata.json.bz2.  El  primer  archivo  que  contenga  dentro  uno 
archivo  comprimido  ZIP  sera  usado. 


MYSQL  y los  fixtures 


Desafortunadamente,  MySQL  no  es  capaz  de  dar  soporte  completo  para  todas  las 
caracteristicas  de  las  fixtures  de  Django.  Si  usas  tablas  MylSAM,  MySQL  no  admite 
transacciones  ni  restricciones,  por  lo  que  no  tendras  rollback  si  se  encuentran  varios 
archivos  de  transaction,  ni  validation  de  los  datos  de  fixture.  Si  usas  tablas  InnoDB, 
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no  podras  tener  referencias  hacia  adelante  en  tus  archivos  de  datos  - MySQL  no 
provee  un  mecanismo  para  retrasar  el  chequeo  de  las  restricciones  de  registro  hasta 
que  la  transaction  es  realizada. 

fixtures  especificos  en  bases  de  datos 

Si  estas  instalando  multiples  bases  de  datos,  tal  vez  tengas  algunos  datos  que  quieras 
cargar  en  una  base  de  datos,  pero  no  en  otra.  En  esta  situation  puedes  agregar  el 
identificador  de  la  base  de  datos  en  el  nombre  de  los  fixtures. 

Por  ejemplo,  si  la  configuration  DATABASES  tiene  una  base  de  datos  definida 
como  maestra,  el  nombre  del  fixture  puede  ser  datos. maestra.json  o 
datos.maestra.json.gz,  de  esta  forma  el  fixture  unicamente  cargara  los  datos  en  la 
base  de  datos  llamada  maestra. 

makemessages 

django-admin.py  makemessages 

Se  ejecuta  completamente  sobre  el  directorio  actual  y recopila  todas  las  cadenas 
marcadas  para  traduction.  Crea  (o  actualiza)  un  archivo  de  mensajes  en  conf/locale 
(en  el  arbol  de  Django)  o en  el  directorio  local  (para  el  proyecto  y aplicacion). 
Despues  de  hacer  los  cambios  a los  archivos  de  mensajes,  es  necesario  compilarlos 
con  compilemessages  para  usarlos  con  el  soporte  incorporado  gettext. 

Elsa  la  option  --all  o -a  para  actualizar  un  archivo  de  mensajes  para  todos  los 
lenguajes  disponibles. 

Ejemplo  de  su  uso: 

django-admin.py  makemessages -all 

-extension 

Elsa  la  option  —extension  o -e  para  especificar  una  lista  de  extensiones  de  archivos 
aexaminar  (default:”.html”,  ”.txt”). 

Ejemplo  de  su  uso: 

django-admin.py  makemessages  -locale=de  -extension  xhtml 

Separa  multiples  extensiones  con  comas  o usa  -e  o -extension  varias  veces: 
django-admin.py  makemessages  -locale=de  -extension=html,txt  -extension  xml 

■ Elsa  la  option  —locale  (o  su  version  corta  -1)  para  especificar  procesos  de 
localizacion(es). 

■ Elsa  la  option  —exclude  (o  su  version  corta"  -x")  para  especificar 
localization  (es)  para  excluir  del  procesamiento.  Si  no  se  le  provee,  ninguna 
localization  sera  excluida. 

Ejemplo  de  su  uso: 

django-admin.py  makemessages  -locale=pt_BR 
django-admin.py  makemessages  -locale=pt_BR  -locale=fr 
django-admin.py  makemessages  -I  pt_BR 
django-admin.py  makemessages  -I  pt_BR  -I  fr 
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django-admin.py  makemessages  -exclude=pt_BR 
django-admin.py  makemessages  -exclude=pt_BR  --exclude=fr 
django-admin.py  makemessages  -x  pt_BR 
django-admin.py  makemessages  -x  pt_BR  -x  fr 


makemigrations  [<app_label>] 
django-admin.py  makemigrations 

Crea  las  nuevas  migraciones  basadas  en  los  cambios  detectados  en  los  modelos. 

Proveer  uno  o mas  nombres  de  aplicaciones  como  argumentos  limitara  las 
migraciones  creadas  en  las  aplicaciones  especificadas  y cualquier  dependencia 
necesaria  (por  ejemplo  en  las  tablas  del  otro  extremo  de  las  relaciones  ForeignKey) 

-empty 

La  option  —empty  permitira  que  la  salida  de  makemigrations  sea  una  migration 
vacia  para  la  aplicacion  especificada,  para  editarla  manualmente.  Esta  option 
deberia  ser  usada,  solo  por  usuarios  avanzados,  que  esten  familiarizados  con  el 
formato  de  migraciones,  operaciones  de  migraciones  y las  dependencias  entre 
migraciones. 

-dry-run 

La  option  --dry-run  muestra  que  migraciones  seran  aplicadas,  sin  escribir  en  los 
archivos  de  migraciones  del  disco.  Usa  esta  option  con  —verbosity  3 para  mostrar  los 
archivos  completos  de  migraciones  que  seran  escritos. 

-merge 

La  option  --merge  permite  corregir  conflictos  de  migraciones.  La  option  —noinput 
puede  ser  provista  para  suprimir  mensajes  de  confirmation  en  la  terminal  del 
usuario,  como  confirmaciones  de  borrado,  etc.  durante  la  fusion. 

-name  -n 

La  option  —name  permite  dar  a las  migraciones  un  nombre  personalizado  en  vez 
del  generado  automaticamente. 


migrate  [<app_label>  [<migrationname>]] 
django-admin.py  migrate 

Sincroniza  el  estado  de  la  base  de  datos,  con  el  actual  conjunto  de  modelos  y 
migraciones. 

El  comportamiento  de  este  comando  cambia  dependiendo  de  los  argumentos 
provistos: 

■ Sin  argumentos:  Todas  las  aplicaciones  que  contienen  migraciones  son 
migradas  y todas  las  aplicaciones  no  emigradas  son  sincronizadas  con  la  base 
de  datos. 
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■ <appjabel>:  La  aplicacion  en  particular  que  tiene  migraciones  a ejecutar, 
hasta  la  migracion  reciente.  Esto  puede  implicar  ejecutar  las  migraciones  de 
otras  aplicaciones  tambien,  debido  a las  dependencias. 

■ <app_label>  <migrationname>:  Trae  el  esquema  de  la  base  de  datos  a un 
estado  donde  se  ejecuto  la  migracion  dada,  pero  no  mas  alia  - esto  conlleva 
desaplicar  las  migraciones  si  se  ha  emigrado  previamente  a la  denominado 
migracion.  Usa  el  nombre  zero  para  desaplicar  todas  las  migraciones  para  una 
aplicacion. 


--fake 


La  opcion  —database  puede  usarse  para  especificar  la  base  de  datos  a migrar. 

La  opcion  —fake  le  dice  a Django  que  marque  la  migracion  como  aplicadas  o no 
aplicadas,  pero  sin  ejecutar  SQ1  realmente,  para  cambiar  el  esquema  de  la  base  de 
datos. 

Esta  disenado  para  el  uso  de  usuarios  avanzados  que  pueden  manipular 
directamente  el  estado  actual  de  las  migraciones,  si  estan  aplicando  manualmente 
cambios;  sea  cuidadoso  usando  y ejecutando  —fake,  ya  que  se  corre  el  riesgo  de 
poner  las  tablas  en  un  estado,  donde  sera  necesaria  la  recuperation  manual,  para  que 
las  migraciones  se  ejecutan  correctamente. 

--list,  -I 

La  opcion  --list  permite  listar  todas  las  aplicaciones  que  Django  sabe  que  tienen 
disponibles  migraciones  por  cada  aplicacion  y si  estan  aplicadas  o no  (marcandolas 
con  una  [X]  junto  al  nombre  de  la  migracion) 

Las  aplicaciones  sin  migraciones  son  unicamente  incluidas  en  la  lista,  pero  con  el 
nombre  (no  migrations)  impreso  debajo  de  ellas. 

runserver  [numero  de  puerto  opcional,  o direccionIP:puerto] 

django-admin.py  runserver 

Inicia  un  servidor  Web  liviano  de  desarrollo  en  la  maquina  local.  Por  omision,  el 
servidor  se  ejecuta  en  el  puerto  8000  de  la  direccion  IP  127.0.0.1.  Puedes  pasarle 
explicitamente  una  direccion  IP  y un  numero  de  puerto. 

Si  ejecutas  este  script  como  un  usuario  con  privilegios  normales  (recomendado), 
puedes  no  tener  acceso  a iniciar  un  puerto  en  un  numero  de  puerto  bajo.  Los 
numeros  de  puerto  bajos  son  reservados  para  el  superusuario  (root). 


® Advertencia:  No  uses  este  servidor  en  una  configuration  de  produccion.  No 

se  le  han  realizado  auditorias  de  seguridad  o tests  de  performance,  y no  hay  planes  de 
cambiar  este  hecho.  Los  desarrolladores  de  Django  estan  en  el  negocio  de  hacer  Web 
frameworks,  no  servidores  Web,  por  lo  que  mejorar  este  servidor  para  que  pueda 
manejar  un  entorno  de  produccion  esta  fuera  del  alcance  de  Django. 


El  servidor  de  desarrollo  carga  automaticamente  el  codigo  Python  para  cada 
pedido  segun  sea  necesario.  No  necesitas  reiniciar  el  servidor  para  que  los  cambios 
en  el  codigo  tengan  efecto. 

Cuando  inicias  el  servidor,  y cada  vez  que  cambies  codigo  Python  mientras  el 
servidor  esta  ejecutando,  este  validara  todos  tus  modelos  instalados.  (Ver  la  section 
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que  viene  sobre  el  comando  validate.)  Si  el  validador  encuentra  errores,  los  imprimira 
en  la  salida  estandar,  pero  no  detendra  el  servidor. 

Puedes  ejecutar  tantos  servidores  como  quieras,  siempre  que  ejecuten  en  puertos 
separados.  Solo  ejecuta  django-admin.py  runserver  mas  de  una  vez. 

Observa  que  la  direccion  IP  por  omision,  127.0.0.1,  no  es  accesible  desde  las  otras 
maquinas  de  la  red.  Para  hacer  que  el  servidor  de  desarrollo  sea  visible  a las  otras 
maquinas  de  la  red,  usa  su  propia  direccion  IP  (ej.:  192.168.2.1)  o 0.0. 0.0. 

Por  ejemplo,  para  ejecutar  el  servidor  en  el  puerto  7000  en  la  direccion  IP 
127.0.0.1,  usaesto: 

django-admin.py  runserver  9000 

O para  ejecutar  el  servidor  en  el  puerto  9000  en  la  direccion  IP  1. 2.3.4,  usa  esto: 
django-admin.py  runserver  1.2.3.4:9000 
--noreload 

Usa  la  opcion  —noreload  para  deshabilitar  el  uso  de  el  recargado  automatico.  Esto 
significa  que  cualquiera  de  los  cambios  que  hagas  en  el  codigo,  no  hara  que  el 
servidor  se  recargue,  mientras  el  servidor  se  esta  ejecutando,  por  lo  que  solo  se 
usaran  los  modulos  especificos  de  Python  que  se  hayan  cargado  en  la  memoria. 
Ejemplo  de  su  uso: 

django-admin.py  runserver  -noreload 

— ipv6,  -6 

Usa  la  opcion  — ipv6  (o  su  version  corta  -6)  para  decide  a Django  que  use  IPv6  para  el 
servidor  de  desarrollo.  Esta  cambia  la  direccion  predeterminada  IP  de  127.0.0.1  a ::1. 

Ejemplo  de  su  uso: 

django-admin.py  runserver  -ipv6 

Ejemplos  de  diferentes  usos  de  puertos  y direcciones 

Puerto  8000  en  direccion  IP  127.0.0.1: 
django-admin.py  runserver 

Puerto  8000  en  direccion  IP  1. 2.3.4: 
django-admin.py  runserver  1.2.3.4:8000 
Puerto  7000  en  direccion  IP  127.0.0.1: 
django-admin.py  runserver  7000 
Puerto  7000  en  direccion  IP  1.2.3.4: 
django-admin.py  runserver  1.2.3.4:7000 
Puerto  8000  en  direccion  IPv6  ::1: 
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django-admin.py  runserver  -6 
Puerto  7000  en  direccion  IPv6  ::1: 
django-admin.py  runserver  -6  7000 

Puerto  7000  en  direccion  IPv6  2001:0db8:1234:5678::9: 
django-admin.py  runserver  [2001:0db8:1234:5678::9]:7000 
Puerto  8000  en  direccion  IPv4  del  host  localhost: 
django-admin.py  runserver  localhost:8000 

Puerto  8000  en  la  direccion  IPv6  del  host  localhost:: 
django-admin.py  runserver  -6  localhost:8000 
shell 

django-admin.py  shell 

Inicia  el  interprete  interactive  de  Python. 

Django  utilizara  IPython  o bpython  si  estan  instalados,  para  iniciar  un  shell 
mejorado.  Pero  si  quieres  forzar  el  uso  del  interprete  Python  “piano”,  usa  la  option  — 
plain,  como  en: 

django-admin.py  shell  -plain 

Si  quieres  especificar  entre  IPython  o bpython  como  tu  interprete,  si  tienes  ambos 
instalados,  puedes  especificar  alternativamente  la  interface  que  quieras  usar,  usando 
la  option  -i  o --interface  asi: 

IPython: 

django-admin.py  shell  -i  ipython 
django-admin.py  shell  -interface  ipython 

bpython: 

django-admin.py  shell  -i  bpython 
django-admin.py  shell  -interface  bpython 

Cuando  el  interprete  interactivo  “piano”  inicia,  (ya  sea  porque  usaste  la  option  — 
plain  o porque  no  tienes  otra  interface  disponible)  este  lee  el  script  que  apunta  a las 
variables  de  entorno  de  PYTHONSTARTUP  y al  script  de  la  variable  -/.pythonrc.py  , 
si  quieres  cambiar  este  comportamiento  usa  la  option  -no-startup,  por  ejemplo: 

sql  <app_label  app_label  ...> 

django-admin.py  sql 

Imprime  las  sentencias  SQL  CREATE  TABLE  para  las  aplicaciones  mencionadas. 
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La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la  cual 
imprimir  el  SQL. 

sqlall  <app_label  app_label  ...> 

django-admin.py  sqlall 

Imprime  las  sentencias  SQL  CREATE  TABLE  y los  datos  iniciales  para  las  aplicaciones 
mencionadas. 

Busca  en  la  description  de  sqlcustom  para  una  explication  de  como  especificar  los 
datos  iniciales. 

La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la  cual 
imprimir  el  SQL. 

sqlclear  <app_label  app_label  ...> 
django-admin.py  sqlclear 

Imprime  las  sentencias  SQL  DROP  TABLE  para  las  aplicaciones  mencionadas. 

La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la 
cual  imprimir  el  SQL. 

sqlcustom  <app_label  app_label  ...> 

django-admin.py  sqlcustom 

Imprime  las  sentencias  SQL  personalizadas  para  las  aplicaciones  mencionadas. 

Para  cada  modelo  en  cada  aplicacion  especificada,  este  comando  busca  el  archivo 
<appname>/sql/<modelname>.sql,  donde  <appname>  es  el  nombre  de  la  aplicacion 
dada  y <modelname>  es  el  nombre  del  modelo  en  minusculas.  Por  ejemplo,  si  tienes 
una  aplicacion  news  que  incluye  un  modelo  Story,  sqlcustom  tratara  de  leer  un 
archivo  news/sql/story.sql  y lo  agregara  a la  salida  de  este  comando. 

Se  espera  que  cada  uno  de  los  archivos  SQL,  si  son  dados,  contengan  SQL  valido. 
Los  archivos  SQL  son  canalizados  directamente  a la  base  de  datos  despues  que  se 
hayan  ejecutado  todas  las  sentencias  de  creation  de  tablas  de  los  modelos.  Usa  este 
enlace  SQL  para  hacer  cualquier  modification  de  tablas,  o insertar  funciones  SQL  en 
las  bases  de  datos. 

Observa  que  el  orden  en  que  se  procesan  los  archivos  SQL  es  indefinido.  La  opcion 
—database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la  cual  imprimir  el 
SQL. 

sqldropindexes  <app_label  app_label  ...> 

django-admin.py  sqldropindexes 

Imprime  las  sentencias  SQL  DROP  INDEX  SQL  para  las  aplicaciones  mencionadas. 

La  opcion  -database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la 
cual  imprimir  el  SQL. 

sqlflush 

django-admin.py  sqlflush 

Imprime  las  sentencias  SQL  que  seran  ejecutadas  por  el  comando  flush. 
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La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la 
cual  imprimir  el  SQL. 

sqlindexes  <app_label  app_label  ...> 

django-admin.py  sqlindexes 

Imprime  las  sentencias  SQL  CREATE  INDEX  para  las  aplicaciones  mencionadas. 

La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la 
cual  imprimir  el  SQL. 

sqlmigrate  <app_label>  <migrationname> 

django-admin.py  sqlmigrate 

Imprime  el  SQL  para  el  nombre  de  la  migracion.  Esta  requiere  una  conexion  a una 
base  de  datos  activa,  que  se  utilizara  para  resolver  restricciones  de  nombres;  esto 
significa  que  se  debe  generar  el  SQL  contra  una  copia  de  la  base  de  datos  que  se  desea 
aplicar  mas  adelante. 

Observa  que  sqlmigrate  no  coloriza  la  salida. 

La  opcion  -database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la 
cual  imprimir  el  SQL. 

-backwards 

De  forma  predeterminada  el  SQL  creado,  permite  ejecuta  las  migraciones  que  siguen. 
Pasandole  la  opcion  —backwards  al  SQL  generado  permite  desaplicar  las 
migraciones. 

sqlsequencereset  <app_label  app_label  ...> 
django-admin.py  sqlsequencereset 

Imprime  las  sentencias  SQL  para  resetear  series  para  las  aplicaciones  mencionadas. 
Las  series  o secuencias  son  indices  usados  por  algunos  motores  de  base  de  datos  para 
rastrear  el  numero  disponible  siguiente  para  los  campos  automaticamente 
incrementados. 

Use  este  comando  para  generar  SQL  que  corrija  casos  donde  una  secuencia  esta 
fuera  de  sincronizacion  con  campos  automaticamente  incrementados. 

La  opcion  —database  puede  ser  usada  para  especificar  la  base  de  datos  sobre  la 
cual  imprimir  el  SQL. 

squashmigrations  <app_label>  <migration_name> 

django-admin.py  squashmigrations 

Compacta  las  migraciones  para  una  aplicacion  dada  (appjabel),  hasta  el  nombre  de 
la  migracion  (migration_name)  incluyendola  y compactandolas  lo  mas  posible,  las 
migraciones  resultantes  pueden  convivir  de  forma  segura  con  migraciones  'no 
compactadas  (unsquashed). 


-no-optimize 
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De  forma  predeterminada,  Django  trata  de  optimizar  las  operaciones  de 
migraciones  para  reducir  el  tamano  de  los  archivos  resultantes.  Sin  embargo  puedes 
usar  la  opcion  — no-optimize,  si  el  proceso  esta  fallando  o si  esta  creando  migraciones 
incorrectas. 

startapp  <app_label>  [destino] 
django-admin.py  startapp 

Crea  una  estructura  de  directorios  para  una  aplicacion  Django  con  el  nombre  de  la 
aplicacion  dada,  en  el  directorio  actual. 

De  forma  predeterminada  el  directorio  creado  contiene  un  archivo  models.py  y 
otros  archivos  para  una  aplicacion  ('views.py,  admin.py...). 

Si  se  le  proporciona  un  destino  optional,  Django  utilizara  el  directorio  existente 
para  crear  uno  nuevo.  Puedes  utilizar”.”  para  denotar  el  directorio  de  trabajo  actual. 
Por  ejemplo: 

django-admin.py  startapp  myapp /Users/jezdez/Code/myapp 
-template 

Con  la  opcion  template  —template,  puedes  utilizar  plantillas  personalizadas  para  una 
aplicacion,  proporcionando  la  ruta  al  directorio  que  contiene  las  plantillas  de 
archivos  o la  ruta  a los  archivos  comprimidos  (.tar.gz,  .tar.bz2,  .tgz,  .tbz,  .zip)  que 
puedan  contener  los  archivos  de  plantillas  para  la  aplicacion. 

Por  ejemplo,  esto  buscaria  plantillas  para  una  aplicacion  en  el  directorio  miapp: 

django-admin.py  startapp  -template=/Users/jezdez/Code/my_app_template  myapp 

Django  tambien  acepta  URLs  (http,  https,  ftp)  para  archivos  comprimidos  que 
contengan  archivos  de  plantillas  para  una  aplicacion,  descargando  y extrayendo  los 
archivos  al  vuelo. 

Por  ejemplo,  aprovechando  la  caracteristica  de  Github  de  exponer  repositories  como 
archivos  zip,  puedes  utilizar  un  URL  como  esta: 

django-admin.py  startapp  ~template=https://github.com/githubuser/django-app- 
template/archive/master.zip  myapp 

Cuando  Django  copia  los  archivos  de  plantillas  de  una  aplicacion,  tambien 
renderiza  ciertos  archivos  a traves  del  motor  de  plantillas:  los  archivos  cuyas 
extensiones  coincidan  con  la  opcion  —extension  (py  por  defecto)  y los  archivos 
cuyos  nombres  sean  pasados  con  la  opcion  —name. 

La  clase  django.template.Context  usa  para  esto,  cualquier  opcion  pasada  al 
comando  startapp  (Entre  las  opciones  soportadas  por  el  comando) 

■ app_name  - el  nombre  de  la  aplicacion  pasada  al  comando. 

■ app_directory - la  ruta  completa  a la  aplicacion  recien  creada. 

■ docs_  version  - la  version  de  la  documentation:  'dev'  o '1.x' 

startproject  <projectname>  [destino] 
django-admin.py  startproject 

Crea  una  estructura  de  directorios  Django  para  el  nombre  de  proyecto  dado,  en  el 
directorio  actual  o en  el  directorio  dado. 
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De  forma  predeterminada,  el  nuevo  directorio  contiene  un  archivo  manage.py  y un 
paquete  de  proyecto  (que  contiene  un  archivo  settings.py  y otros  archivos),  si  solo  el 
nombre  de  proyecto  es  dado,  tanto  el  directorio  del  proyecto  y el  paquete  del 
proyecto  seran  llamados  <projectname>  y el  directorio  del  proyecto  sera  creado  en  el 
directorio  de  trabajo  actual. 

Si  se  le  provee  la  opcion  destino,  Django  usara  el  directorio  existente  como  el 
directorio  del  proyecto  y creara  un  archivo  manage.py  y el  paquete  del  proyecto 
dentro  del.  Usa  V para  denotar  el  actual  directorio  de  trabajo. 

Por  ejemplo: 

django-admin.py  startproject  myproject  /Users/jezdez/Code/myproject_repo 

A1  igual  que  el  comando  startapp  la  opcion  —template  permite  especificar  un 
directorio,  una  ruta  de  archivos  o una  URL  para  proveer  de  plantillas  personalizadas 
al  proyecto. 

Por  ejemplo,  esto  buscara  plantillas  para  un  proyecto  en  el  directorio  dado,  cuando 
se  cree  el  proyecto  myproject: 

django-admin.py  startproject  -template=/Users/jezdez/Code/my_project_template 
myproject 

Tambien  acepta  URLs  (http,  https,  ftp)  para  archivos  comprimidos  que  contengan 
archivos  de  plantillas  para  un  proyecto,  descargando  y extrayendo  los  archivos  al 
vuelo. 

Por  ejemplo,  aprovechando  la  caracteristica  de  Github  de  exponer  repositorios 
como  archivos  zip,  puedes  utilizar  un  URL  como  esta: 

django-admin.py  startproject  ~template=https://github.com/githubuser/django-project- 
template/archive/master.zip  myproject 

Cuando  Django  copia  los  archivos  de  plantillas  de  un  proyecto,  tambien  renderiza 
ciertos  archivos  a traves  del  motor  de  plantillas:  los  archivos  cuyas  extensiones 
coincidan  con  la  opcion  —extension  (py  por  defecto)  y los  archivos  cuyos  nombres 
sean  pasados  con  la  opcion  —name. 

La  clase  django.template.Context  usa  para  esto,  cualquier  opcion  pasada  al 
comando  startapp  (Entre  las  opciones  soportadas  por  el  comando) 

■ project_name  - el  nombre  del  proyecto  pasado  al  comando. 

■ project_directory  - la  ruta  completa  al  proyecto  recien  creado. 

■ secret _key  - una  clave  al  azar  para  la  configuration  de  SECRET_KEY. 

■ docs_version  - la  version  de  la  documentation:  'dev'  o ' 1.x' 


test 

django-admin.py  test 

Ejecuta  todas  las  pruebas  para  todos  los  modelos  instalados. 

— failfast 

La  opcion  —failfast  se  usa  para  detener  las  pruebas  y reportar  las  fallas 
inmediatamente  despues  de  que  una  prueba  falla. 


— testrunner 
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La  opcion  — testrunner  es  usada  para  controlar  la  clase  de  pruebas  que  es  usada  para 
ejecutar  las  pruebas.  Si  este  valor  es  proporcionado  al  comando,  sobrescribira  el  valor 
provisto  por  la  configuration  TEST_RUNNER. 

— liveserver 

La  opcion  —liveserver  es  usada  para  sobrescribir  la  direction  predeterminada  que  usa 
el  servidor  de  pruebas,  (usado  con  LiveServerTestCase.)  El  valor  predeterminado  es 
localhost:8081. 

--keepdb 

La  opcion  —keepdb  es  usada  para  preservar  los  test  en  la  base  de  datos  entre  la 
ejecucion  de  pruebas.  Este  toma  la  ventaja  de  saltarse  el  crear  y destruir  las  tablas 
entre  prueba  y prueba,  esto  disminuye  en  gran  medida  el  tiempo  de  pruebas, 
especialmente  en  grandes  suits  de  pruebas.  Si  la  base  de  datos  de  tests  no  existe,  esta 
se  crea  la  primera  vez  que  se  ejecuta  y se  preserva  en  cada  subsecuente  ejecucion. 
Cualquier  migration  no  aplicada  sera  aplicada  a la  base  de  datos  de  pruebas  antes  de 
ejecutar  todas  las  pruebas. 

testserver  <fixture  fixture  ...> 

django-admin.py  testserver 

Ejecuta  un  servidor  de  desarrollo  Django  (como  runserver)  usando  datos 
proporcionados  por  fixture (s) 

Por  ejemplo,  este  comando: 

django-admin.py  testserver  mydata.json 

Realizara  los  siguientes  pasos: 

1.  Creara  una  base  de  datos  de  pruebas. 

2.  Poblara  la  base  de  datos  de  pruebas  con  datos  provistos  por  los  fixtures. 

3.  Ejecutar  el  servidor  de  desarrollo  (tal  como  runserver)  apuntado  a la  base  de 
datos  recien  creada  en  lugar  de  la  base  de  datos  de  production. 

Comandos  provistos  por  aplicaciones 


Algunos  comando  son  unicamente  disponibles  cuando  la  aplicacion  django.contrib 
ha  sido  activada.  Esta  section  describe  los  comandos  provistos  por  cada  aplicacion. 

django.contrib.auth 

changepassword 

django-admin.py  changepassword 

Este  comando  se  encuentra  unicamente  disponible,  si  se  instala  el  sistema  de 
autentificacion  (django.contrib.auth.) 

Permite  cambiar  las  contrasenas  de  los  usuarios.  Instiga  a entrar  dos  veces  la 
contrasena  de  un  usuario  dado,  como  parametro.  Si  ambos  coinciden,  la  nueva 
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contrasena  sera  cambiada  de  inmediato.  Si  no  se  le  pasa  un  usuario,  el  comando 
intentara  usar  el  usuario  actual  para  cambiar  la  contrasena. 

Usa  la  opcion  —database  para  especificar  la  base  de  datos  a consultar  para  el 
usuario.  Si  esta  no  se  le  proporciona,  Django  usara  la  base  de  datos  por  default 
Ejemplo  de  sus  uso: 

django-admin.py  changepassword  ringo 

createsuperuser 
django-admin.py  createsuperuser 

Este  comando  se  encuentra  unicamente  disponible,  si  se  instala  el  sistema  de 
autentificacion  (django.contrib.auth.) 

Crea  una  cuenta  de  superusuario  (un  usuario  que  tiene  todos  los  permisos).  Esto 
es  util  si  necesitas  crear  una  cuenta  inicial  para  un  superusuario  o si  necesitas 
generar  programaticamente  cuentas  de  superusuarios  para  tu  sitio(s). 

Cuando  se  ejecuta  interactivamente,  este  comando  preguntara  por  una 
contrasena  para  crear  la  cuenta  del  superusuario.  Cuando  se  ejecuta  de  forma  no 
interactiva,  es  necesario  configurar  la  contrasena  de  forma  manual. 

--username 

--email 


El  nombre  de  usuario  y la  direction  de  email  para  la  nueva  cuenta,  pueden 
proporcionarse  usando  los  argumentos  --username  y --email  en  la  linea  de 
comandos.  Si  cualquiera  de  ellos  no  se  provee,  createsuperuser  preguntara  por  ellos 
al  ejecutarse  de  forma  interactiva. 

Usa  la  opcion  —database  para  especificar  la  base  de  datos  en  la  que  quieras 
guardar  los  objetos  superusuarios. 

dj  ango.  contrib.gis 

ogrinspect 

Este  comando  se  encuentra  unicamente  disponible,  si  se  instala  el  sistema  de 
Geo  dj  ango  (dj  ango . contrib . gis) . 


django.contrib.sessions 
clearsessions 
django-admin.py  clearsessions 

Puede  ser  usado  como  una  tarea  por  cron  o directamente  para  limpiar  las  sesiones 
que  han  expirado. 

django.contrib.sitemaps 

ping_google 

Este  comando  se  encuentra  unicamente  disponible,  si  se  instala  el  framework  de 
Sitemaps  (django.contrib.sitemaps) . 
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Usado  para  hacer  ping  a Google,  para  que  indexe  nuestro  sitio(s).  Una  vez  que  has 
agregado  la  aplicacion  sitemap  a tu  proyecto,  puedes  hacer  ping  a Google  usando 
este  comando  de  la  siguiente  forma: 

python  manage. py  ping_google  [/sitemap. xml] 

django.contrib.staticfiles 

collectstatic 

Este  comando  se  encuentra  unicamente  disponible,  si  se  instala  el  framework  de 
archivos  estaticos  (django.contrib.staticfiles). 

Usado  para  coleccionar  los  archivos  estaticos  (hojas  de  estilo  css,  js...)  que  seran 
servidos  por  el  servidor  web  en  un  entorno  de  production.  Los  nombres  duplicados 
de  los  archivos  de  forma  predeterminada  se  resuelven  de  una  manera  similar  a como 
lo  hacen  las  plantillas:  el  archivo  que  es  primero  localizado,  es  el  que  se  usara. 

Colecciona  los  archivos  estaticos  en  STATIC_ROOT.  Para  una  lista  completa  de 
opciones,  usa  - -help: 

python  manage. py  collectstatic  -help 

findstatic 

Busca  uno  o mas  caminos  relativos,  a la  ruta  de  los  buscadores  habilitados. 

Por  ejemplo: 

python  manage. py  findstatic  css/base. css  admin/js/core.js 

De  forma  predeterminada,  todas  las  localidades  que  coincidan  seran  encontradas. 
Si  unicamente  quieres  que  devuelva  la  primera  coincidencia  por  cada  ruta  relativa, 
usa  la  option  —first  asi: 

python  manage. py  findstatic  css/base. css  -first 


Opciones  Predeterminadas 


Aunque  algunos  comandos  pueden  permitir  sus  propias  opciones  personalizadas, 
cada  comando  permite  usar  las  siguientes  opciones: 

Las  secciones  que  siguen  delinean  las  opciones  que  puede  tomar  django-admin.py 
en  la  mayoria  de  casos. 

—settings 

Especifica  explicitamente  el  modulo  de  configuration  a usar.  El  modulo  de 
configuration  debe  estar  en  la  sintaxis  de  paquetes  de  Python  (ej . : mysite. settings).  Si 
no  se  proveen,  django-admin.py  utilizara  la  variable  de  entorno 
DJANGO_SETTINGS_MODULE. 

Ejemplo  de  uso: 

django-admin.py  migrate  -settings=mysite. settings 
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Observa  que  esta  opcion  no  es  necesaria  en  manage.py,  ya  que  toma  en  cuenta  la 
configuration  de  DJANGO_SETTINGS_MODULE  por  t± 

— pythonpath 

Agrega  la  ruta  del  sistema  de  archivos  a la  ruta  de  busqueda  de  importation  de 
Python.  Si  no  se  define,  django-admin.py  usara  la  variable  de  entorno  PYTHONPATH. 
Ejemplo  de  uso: 

django-admin.py  migrate  -pythonpath='/home/djangoprojects/myproject' 

Observa  que  esta  opcion  no  es  necesaria  en  manage.py,  ya  que  este  comando  tiene 
cuidado  de  configurar  la  ruta  de  Python  por  ti. 

—format 

Especifica  el  formato  de  salida  que  sera  utilizado.  El  nombre  provisto  debe  ser  el 
nombre  de  un  serializador  registrado. 

Ejemplo  de  uso: 

django-admin.py  dumpdata  -format=xml 


—help 


Muestra  un  mensaje  de  ayuda  que  incluye  una  larga  lista  de  todas  las  opciones  y 
acciones  disponibles. 

-traceback 

De  forma  predeterminada  django-admin  muestra  un  simple  mensaje  de  error 
cuando  ocurre  un  CommandError,  pero  muestra  una  traza  completa  para  cualquier 
otra  exception.  Si  especificas  la  opcion  —traceback,  django-admin  tambien  mostrara 
la  traza  de  pila  completa  cuando  ocurra  algun  error  de  comando  o CommandError. 
Por  ejemplo: 

django-admin.py  migrate  -traceback 

-no-color 

De  forma  predeterminada  el  formato  que  usa  django-admin  para  mostrar  las  salidas 
es  colorizado.  Por  ejemplo,  los  errores  se  imprimen  en  la  consola  en  rojo  y las 
declaraciones  en  SQL  aparecen  con  resaltado  de  sintaxis.  Para  prevenir  esto  y mostrar 
la  salida  de  texto  piano,  es  necesario  pasarle  la  opcion  -no-color  al  ejecutar  el 
comando,  de  la  siguiente  forma: 

django-admin.py  sqlall  --no-color 

—version 

Muestra  la  version  actual  de  Django. 

django-admin.py  version 
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Ejemplo  de  salida: 

1.8 

1.9 

—verbosity 

Determina  la  cantidad  de  notificaciones  e informacion  de  depuration  que  se 
imprimira  en  la  consola. 

Ejemplo  de  uso: 

django-admin.py  migrate  --verbosity=2 

Usa  niveles  para  determinar  la  cantidad  de  informacion  a mostrar: 

0 significa  sin  salida. 

1 significa  salida  normal  (default). 

2 significa  salida  con  explicaciones. 

3 significa  mr/pexplicado. 

Opciones  comunes 

Las  siguientes  opciones  no  estan  disponibles  en  cada  comando,  pero  son  muy 
comunes  en  un  gran  numero  de  comandos. 

-database 

Usado  para  especificar  la  base  de  datos  en  la  cual  opera  el  comando.  Si  no  se 
especifica,  esta  opcion  usara  el  valor  predeterminado  por  el  alias  default. 

Por  ejemplo,  para  volcar  datos  de  una  base  de  datos  con  el  alias  master: 

django-admin.py  dumpdata  -database=master 

-exclude 

Excluye  una  aplicacion  en  especifico  de  las  aplicaciones  cuyo  contenido  se  espera  en 
la  salida. 

Por  ejemplo,  para  especificamente  excluir  la  aplicacion  auth  de  la  salida  de 
dumpdata.  Por  ejemplo: 

django-admin.py  dumpdata  -exclude=auth 

Si  quieres  excluir  multiples  aplicaciones,  usa  multiples  directivas  --exclude: 

django-admin.py  dumpdata  -exclude=auth  -exclude=contenttypes 

-indent 

Especifica  el  numero  de  espacios  que  se  utilizaran  para  la  indentacion  cuando  se 
imprima  una  salida  con  formato  de  impresion.  Por  omision,  la  salida  no  tendra 
formato  de  impresion.  El  formato  de  impresion  solo  estara  habilitado  si  se  provee  la 
opcion  de  indentacion. 
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Ejemplo  de  uso: 

django-admin.py  dumpdata  --indent=4 

—noinput 

Indica  que  no  quieres  que  se  te  pida  ninguna  entrada.  Es  util  cuando  el  script  django- 
admin  se  ejecutara  en  forma  automatica  y desatendida. 

-noreload 

Deshabilita  el  uso  del  autoreloader  cuando  se  ejecuta  el  servidor  de  desarrollo. 

-locale 

Usa  la  opcion  --locale  o -1  para  especiflcamente  procesar  una  localidad.  Si  no  provees 
esta  opcion  todas  las  localidades  seran  procesadas. 


Sutilezas  extras 

Sintaxis  de  colores 

Los  comandos  django-admin  / manage.py  usan  un  agradable  resaltado  de  codigo  en 
la  salida  (colores)  mostrada  en  la  terminates  con  soporte  para  salida  ANSI-colored. 

Bajo  Windows,  la  consola  nativa  no  soporta  el  escape  de  secuencias  ANSI,  por  lo 
que  la  salida  no  es  mostrada  con  colores.  Pero  puedes  instalar  una  herramienta  de 
terceros  llamada  ANSICON  ((§)http:adoxa.altervista.org/ansicon/),  el  comando  de 
Django  puede  detectar  si  esta  presente  y usarla  para  mostrar  el  resaltado  de  sintaxis, 
tal  como  en  plataformas  basadas  en  Unix. 

Los  colores  usados  por  el  resaltado  de  sintaxis  pueden  personalizarse.  Django 
viene  con  tres  paletas  de  colores. 

■ dark,  adaptado  apara  terminales  que  muestran  texto  en  bianco  y el  fondo  en 
negro.  Esta  es  la  paleta  predeterminada. 

■ light,  adaptado  para  terminales  que  muestran  el  texto  en  negro  en  un  fondo 
bianco. 

■ nocolor,  desactiva  el  resaltado  de  sintaxis. 

Puedes  seleccionar  una  paleta  configurando  las  variables  de  entorno  para 
DJANGO_COLORS  especificando  la  paleta  a usar.  Por  ejemplo,  para  especificar  la 
paleta  light  bajo  un  shell  tipo  Unix  o OS/X  tipo  shell  BASH,  puedes  usar  el  siguiente 
comando  en  una  terminal: 


export  DJANGO_COLORS="light' 
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Autocompletado  para  bash 

Si  estas  usando  el  shell  Bash,  considera  instalar  el  script  bash  completion  el  cual  se 
localiza  en  extras / d j an go  Jbas h_co rn pletion  en  la  distribution  de  Django.  Este 
habilita  el  autocompletado  usando  la  tecla  tab,  para  los  comandos  django- admin. py 
y manage.py,  con  lo  que  es  posible,  por  ejemplo... 

Tipea  django-admin.py: 

■ Presionar  [TAB]  para  ver  las  opciones  disponibles. 

■ Tipea  sql,  luego  [TAB],  para  ver  todas  las  opciones  disponibles  cuyos  nombres 
comienzan  con  sql. 


APENDICE  G 


Objetos  peticion  y respuesta 


LJ  salos  objetos  peticibn  y respuesta  para  pasar  informacibn  de  estado  a traves  del 
sistema. 

Cuando  se  peticiona  una  pagina,  Django  crea  un  objeto  HttpRequest  que  contiene 
metadatas  sobre  la  peticion.  Luego  Django  carga  la  vista  apropiada,  pasando  el 
HttpRequest  como  el  primer  argumento  de  la  funcion  de  vista.  Cada  vista  es 
responsable  de  retornar  un  objeto  Http  Response. 

Hemos  usado  estos  objetos  con  frecuencia  a lo  largo  del  libro;  este  apendice 
explica  las  APIs  completas  para  los  objetos  HttpRequest  (peticion)  y HttpResponse 
(respuesta). 

HttpRequest 

HttpRequest  representa  una  sola  peticion  HTTP  desde  algun  agente  de  usuario. 

Mucha  de  la  information  importante  sobre  la  peticion  esta  disponible  como 
atributos  en  la  instancia  misma  de  HttpRequest  (mira  la  Tabla  G-l).  Todos  los 
atributos  excepto  session  deben  considerarse  de  solo  lectura. 


Atributo  Description 


path  Un  string  que  representa  la  ruta  completa  a la  pagina  peticionada, 

no  incluye  el  dominio  - por  ejemplo,  "/music/bands/the_beatles/". 

method  Un  string  que  representa  el  metodo  HTTP  usado  en  la  peticion.  Se 

garantiza  que  estara  en  mayusculas.  Por  ejemplo: 

if  request. method  ==  ’GET’: 
do_something() 
elif  request.method  ==  ’POST’: 
do_something_else() 

encoding  Una  cadena  que  representa  la  actual  codification  usada  para 

decodiflcar  los  datos  enviados  por  los  formularios  (o  None),  lo  cual 
significa  que  DEFAULT_CHARSET  se  esta  usando. 

Puedes  rescribir  este  atributo  para  cambiar  la  codification  usada 
para  acceder  a los  datos  del  formulario.  Cualquier  subsecuente 
acceso  a los  atributos  (tales  como  leer  de  GET  o POST  ) usaran  el 
nuevo  valor  del  encoding.  Util  si  sabes  que  los  datos  del  formulario 
no  estan  en  la  en  codification  de  DEFAULT_CHARSET. 


GET  Un  objeto  similar  a un  diccionario  que  contiene  todos  los 

parametros  HTTP  GET  dados.  Mira  la  documentation  de  QueryDict' 
que  sigue. 
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POST 


REQUEST 


COOKIES 


FILES 


META 


Un  objeto  similar  a un  diccionario  que  contiene  todos  los 
parametros  HTTP  POST  dados. Mira  la  documentation  de  QueryDict 
que  sigue. 

Es  posible  que  una  peticion  pueda  ingresar  via  POST  con  un 
diccionario  POST  vacio  - si,  digamos,  un  formulario  es  peticionado 
a traves  del  metodo  HTTP  POST  pero  que  no  incluye  datos  de 
formulario.  Por  eso,  no  deberias  usar  if  request.POST  para  veriflcar 
el  uso  del  metodo  POST;  en  su  lugar,  utiliza  if  request.method  == 
"POST"  (mira  la  entrada  method  en  esta  tabla). 

Nota:  POST  no  incluye  information  sobre  la  subida  de  archivos. 
Mira  FILES. 

Por  conveniencia,  un  objeto  similar  a un  diccionario  que  busca  en 
POST  primero,  y luego  en  GET.  Inspirado  por  $_REQUEST  de  PHP. 
Por  ejemplo,  si  GET  = {"name":  "john"}  y POST  = {"age":  '34'}, 
REQUEST  ["name"]  sera  "john",  y REQUEST  ["age"]  sera  "34".  Se 
sugiere  encarecidamente  que  uses  GET  y POST  en  lugar  de 
REQUEST,  ya  que  lo  primero  es  mas  explicito. 

Un  diccionario  Python  estandar  que  contiene  todas  las  cookies.  Las 
claves  y los  valores  son  strings.  Mira  el  Capitulo  12  para  saber  mas 
de  cookies. 

Un  objeto  similar  a un  diccionario  que  contiene  todos  los  archivos 
subidos.  Cada  clave  de  FILES  es  el  atributo  name  de  <input 
type="file"  name=""  />.  Cada  valor  de  FILES  es  un  diccionario 
Python  estandar  con  las  siguientes  tres  claves: 

■ filename.  El  nombre  del  archivo  subido,  como  un  string 
Python. 

■ content-type.  El  tipo  de  contenido  del  archivo  subido. 

■ content: El  contenido  en  crudo  del  archivo  subido. 

Nota  que  FILES  contendra  datos  solo  si  el  metodo  de  la  peticion  fue 
POST  y el  <form>  que  realizo  la  peticion  contenia 
enctype="multipart/form-data".  De  lo  contrario,  FILES  sera  un 
objeto  similar  a un  diccionario  vacio. 

Un  diccionario  Python  estandar  que  contiene  todos  los  encabezados 
HTTP  disponibles.  Los  encabezados  disponibles  dependen  del 
cliente  y del  servidor,  pero  estos  son  algunos  ejemplos: 

■ CONTENT_LEN  GTH 

■ CONTENT_TYPE 

■ QUERY_STRING:  La  string  de  consulta  en  crudo  sin 
analizar. 

■ REMOTE_ADDR:  La  direction  IP  del  cliente. 

■ REMOTE_HOST:  El  nombre  host  del  cliente. 

■ SERVER_NAME:  El  nombre  host  del  servidor. 

■ SERVER_PORT:  El  puerto  del  servidor. 

Cualquier  cabecera  HTTP  esta  disponible  en  META  como  claves  con 
el  prefijo  HTTP_,  por  ejemplo: 

■ HTTP_ACCEPT_ENCODING 

■ HTTP  ACCEPT  LANGUAGE 
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■ HTTP_HOST:  La  cabecera  HTTP  host  en  viada  por  el 
cliente 

■ HTTP_REFERER:  La  pagina  referente,  si  la  hay 

■ HTTP_USER_AGENT:  La  string  de  agente  de  usuario  del 
cliente 

■ HTTP_X_BENDER:  El  valor  de  la  cabecera  X-Bender,  si 
esta  establecida. 

user  Un  objeto  django.contrib.auth.models.User  que  representa  el 

usuario  actual  registrado.  Si  el  usuario  no  esta  actualmente 
registrado,  user  se  fijara  a una  instancia  de 
django.contrib.auth.models.AnonymousUser.  Puedes  distinguirlos 
con  is_authenticated(),  de  este  modo: 

if  request. user. is_authenticated(): 

# Hacer  algo  para  usuarios  autentificados. 
else: 

# Hacer  algo  para  usuarios  anonimos. 

user  esta  disponible  solo  si  tu  instalacion  Django  tiene  activado 
AuthenticationMiddleware.  Para  los  detalles  completos  sobre 
autenticacion  y usuarios,  mira  el  capitulo  14. 

session  Un  objeto  similar  a un  diccionario  que  se  puede  leer  y modificar, 

que  representa  la  sesion  actual.  Este  esta  disponible  solo  si  tu 
instalacion  Django  tiene  activado  el  soporte  para  sesiones.  Mira  el 
capitulo  14. 

raw_post_data  Los  datos  HTTP  POST  en  crudo.  Esto  es  util  para  procesamiento 
avanzado. 

Tabla  Gl:  A ( rib u (os  delos  objetos HttpRequest 

Los  objetos  request  tambien  tienen  algunos  metodos  de  utilidad,  como  se  muestra  en 
la  Tabla  G-2. 


Metodo 


Description 


getitem (key) 


has_key() 

get_host() 


get_full_path() 

is_secure() 


Retorna  el  valor  GET/POST  para  la  clave  dada,  verificando  POST 
primero,  y luego  GET.  Emite  KeyError  si  la  clave  no  existe. 

Esto  te  permite  usar  sintaxis  de  acceso  a diccionarios  en  una 
instancia  HttpRequest. 

Por  ejemplo,  request["foo"]  es  lo  mismo  que  comprobar 
request.POST["foo"]  yluego  request.GET["foo"]. 

Retorna  True  o False,  senalando  si  request.GET  o request.POST 
contiene  la  clave  dada. 

Devuelve  el  origen  de  la  peticion  usando  informacion  de  las 
cabeceras  HTTP_X_FORWARDED_HOST  y HTTP_HOST  (en  ese 
orden)  Si  no  se  le  proveen  valores,  este  metodo  usa  una 
combinacion  de  SERVER_NAME  y SERVER_PORT 
Retorna  la  ruta,  mas  un  string  de  consulta  agregado.  Por  ejemplo, 
" / music  / bands  /the_beatles  /?print=true " 

Retorna  True  si  la  peticion  es  segura;  es  decir  si  fue  realizada  con 


HTTPS. 
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Tabla  G2:  Metodos  de  HttpRequest 


Objetos  QueryDict 


En  un  objeto  HttpRequest,  los  atributos  GET  y POST  son  instancias  de 
django.http.QueryDict.  QueryDict  es  una  clase  similar  a un  diccionario  personalizada 
para  tratar  multiples  valores  con  la  misma  clave.  Esto  es  necesario  ya  que  algunos 
elementos  de  un  formulario  HTML,  en  particular  <select  multiple="multiple">,  pasan 
multiples  valores  para  la  misma  clave. 

Las  instancias  QueryDict  son  inmutables,  a menos  que  realices  una  copia  de  ellas. 
Esto  significa  que  tu  no  puedes  cambiar  directamente  los  atributos  de  request.POST  y 
request.GET. 

QueryDict  implementa  todos  los  metodos  estandar  de  los  diccionarios,  debido  a que 
es  una  subclase  de  diccionario.  Las  excepciones  se  resumen  en  la  Tabla  G-3. 


Metodo  Diferencias  con  la  implementacion  estandar  de  diet 


getitem Funciona  como  en  un  diccionario.  Sin  embargo,  si  la  clave  tiene  mas 

de  un  valor, getitem ()  retorna  el  ultimo  valor. 

setitem Establece  la  clave  dada  a [value]  (una  lista  de  Python  cuyo  unico 

elemento  es  value).  Nota  que  esta,  como  otras  funciones  de  diccionario 
que  tienen  efectos  secundarios,  solo  puede  ser  llamada  en  un 
QueryDict  mutable  (uno  que  fue  creado  via  copyO). 

get()  Si  la  clave  tiene  mas  de  un  valor,  get()  retorna  el  ultimo  valor  al  igual 

que getitem . 

update!)  Recibe  ya  sea  un  QueryDict  o un  diccionario  estandar.  A diferencia  del 
metodo  update  de  los  diccionarios  estandar,  este  metodo  agrega 
elementos  al  diccionario  actual  en  vez  de  reemplazarlos: 

>»  q = QueryDict(’a=l’) 

>»  q = q. copy()  # to  make  it  mutable 

»>  q.update({’a’:  ’2’}) 

>»  q.getlist(’a  ) 

[T,  ’2’] 

>»  q[’a’]  # returns  the  last 
['2'] 

items!)  Similar  al  metodo  items!)  de  un  diccionario  estandar,  excepto  que  este 

utiliza  la  misma  logica  del  ultimo-valor  de getitem!) : 

>»  q = QueryDict(’a=l&a=2&a=3’) 

>»  q. items() 

[(’a’,  ’3’)] 

values!)  Similar  al  metodo  values!)  de  un  diccionario  estandar,  excepto  que  este 
utiliza  la  misma  logica  del  ultimo-valor  de getitem!) . 

Tabla  G3:  Como  se  diferencian  los  QueryDicts  delos  diccionarios  estandar. 
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Ademas,  QueryDict  posee  los  metodos  que  se  muestran  en  la  Tabla  G-4. 


Metodo  Description 


copyO  Retorna  una  copia  del  objeto,  utilizando  copy.deepcopyO  de  la 

biblioteca  estandar  de  Python.  La  copia  sera  mutable  - es 
decir,  puedes  cambiar  sus  valores. 


getlist(key)  Retorna  los  datos  de  la  clave  requerida,  como  una  lista  de 

Python.  Retorna  una  lista  vacia  si  la  clave  no  existe.  Se 
garantiza  que  retornara  una  lista  de  algun  tipo. 


setlist(key,  list J Establece  la  clave  dada  a list_  (a  diferencia  de setitem ()) • 

appendlist(key,  Agrega  un  elemento  item  a la  lista  interna  asociada  a key. 

item) 


setlistdefaultjkey,  1)  Igual  a setdefault,  excepto  que  toma  una  lista  de  valores  en  vez 

de  un  solo  valor. 

lists 0 Similar  a items 0,  excepto  que  incluye  todos  los  valores,  como 

una  lista,  para  cada  miembro  del  diccionario.  Por  ejemplo: 

»>  q = QueryDict('a=l&a=2&a=3') 

»>  q.listsO 
[('a',  [T/2','3'])] 


urlencodeQ 


Retorna  un  string  de  los  datos  en  formato  query-string  (ej., 
"a=2&b=3&b=5"). 


Tabla  G4  Metodos  QueryDict  Extra  (No  relacionados  con  diccionarios) 


Un  ejemplo  completo 

Por  ejemplo,  dado  este  formulario  HTML: 

<form  action=7foo/bar/'  method="post"> 

<input  type="text"  name="tu_nombre"  /> 

<select  multiple-'multiple"  name="bandas"> 

<option  value="beatles">The  Beatles</option> 

<option  value="who">The  Who</option> 

<option  value="zombies">The  Zombies</option> 

</select> 

<input  type="submit"  /> 

</form> 

Si  el  usuario  ingresa  "John  Smith"  en  el  campo  "tu_nombre"  y selecciona  tanto  “The 
Beatles”  como  “The  Zombies”  en  la  caja  de  selection  multiple,  lo  siguiente  es  lo  que 
contendra  el  objeto  request  de  Django: 

»>  request. GET 

{} 

»>  request. POST 

{’tu_nombre’:  [’John  Smith’],  ’bandas’:  [’beatles’,  ’zombies’]} 
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»>  request.  POST[  tu_nombre'] 

’John  Smith’ 

»>  request.  POST[’bandas’] 

’zombies’ 

»>  request. POST.getlist(’bandas’) 

[’beatles’,  ’zombies’] 

»>  request. POST. get(’tu_nombre',  ’Adrian’) 

’John  Smith’ 

»>  request. POST. get(’nonexistent_field’,  ’Nowhere  Man’) 
’Nowhere  Man’ 


Nota:Los  atributos  GET,  POST,  COOKIES,  FILES,  META,  REQUEST,  raw_post_data, 
y user  son  todos  cargados  tardiamente.  Esto  significa  que  Django  no  gasta  recursos 
calculando  los  valores  de  estos  atributos  hasta  que  tu  codigo  los  solicita. 


HttpResponse 

A diferencia  de  los  objetos  HttpRequest,  los  cuales  son  creados  automaticamente  por 
Django,  los  objetos  HttpResponse  son  tu  responsabilidad.  Cada  vista  que  escribas  es 
responsable  de  instanciar,  poblar,  y retornar  un  HttpResponse. 

La  clase  HttpResponse  esta  ubicada  en  django.http. HttpResponse. 


Construccion  de  HttpResponses 

Tipicamente,  tu  construiras  un  HttpResponse  para  pasar  los  contenidos  de  la  pagina, 
como  un  string,  al  constructor  de  HttpResponse: 

>»  response  = HttpResponse("Este  es  texto  de  una  pagina  Web. ') 

»>  response  = HttpResponse(”Unicamente  texto. ",  mimetype-'text/plain") 

Pero  si  quieres  agregar  contenido  de  manera  incremental,  puedes  usar  response 
como  un  objeto  similar  a un  archivo: 

»>  response  = HttpResponse() 

»>  response.write("<p>  Este  es  texto  de  una  pagina  Web.</p>") 

»>  response. write("<p>Este  es  un  parrafo.</p>") 

Puedes  pasarle  a HttpResponse  un  iterador  en  vez  de  pasarle  strings  codificadas  a 
mano.  Si  utilizas  esta  tecnica,  sigue  estas  instrucciones: 

• El  iterador  debe  retornar  cadenas  o strings. 

• Si  un  HttpResponse  ha  sido  inicializado  con  un  iterador  como  su  contenido, 
no  puedes  usar  la  instancia  HttpResponse  como  un  objeto  similar  a un 
archivo.  Si  lo  haces,  emitira  Exception. 

Finalmente,  nota  que  HttpResponse  implementa  un  metodo  write(),  lo  cual  lo  hace 
apto  para  usarlo  en  cualquier  lugar  que  Python  espere  un  objeto  similar  a un  archivo. 
Mira  el  Capftulo  11  para  ver  algunos  ejemplos  de  la  utilization  de  esta  tecnica. 
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Establecer  las  cabeceras 

Puedes  agregar  o eliminar  cabeceras  usando  sintaxis  de  diccionario: 

>»  response  = HttpResponse() 

»>  response[’X-DJANGO’]  = "Es  el  mejor." 

»>  del  response[  X-PHP’] 

»>  response[’X-DJANGO’] 

" Es  el  mejor." 

Puedes  utilizar  tambien  has_header(header)  para  verificar  la  existencia  de  una 
cabecera. 

Evita  configurar  cabeceras  Cookie  a mano;  en  cambio,  mira  el  capltulo  15  para 
instrucciones  sobre  como  trabajan  las  cookies  en  Django. 

Subclases  de  HttpResponse 

Django  incluye  un  numero  de  subclases  HttpResponse  que  manejan  diferentes  tipos 
de  respuestas  HTTP  (mira  la  Tabla  G-5).  Asi  como  HttpResponse,  estas  subclases  se 
encuentran  en  django.http. 


Clase  Descripcion 


Clase 

Descripcion 

HttpResponseRedirect 

El  constructor  toma  un  unico  argumento:  la  ruta 
a la  cual  re-dirigir.  Esta  puede  ser  una  URL 
completa  (ej.,  'http://search.yahoo.com/')  o o 
una  URL  absoluta  sin  dominio  (ej.,  '/search/'). 
Ten  en  cuenta  que  esto  retorna  un  codigo  de 
estado  HTTP  302. 

HttpResponsePermanentRedirect 

Como  HttpResponseRedirect,  pero  esta  retorna 
una  re-direccion  permanente  (codigo  de  estado 
HTTP  301)  en  vez  de  una  re-direccion  “found” 
(codigo  de  estado  302). 

HttpResponseNotModified 

El  constructor  no  tiene  ningun  argumento. 
Utiliza  esta  para  designar  que  una  pagina  no  ha 
sido  modificada  desde  la  ultima  petition  del 
usuario. 

HttpResponseBadRequest 

Actua  como  HttpResponse  pero  usa  un  codigo  de 
estado  400. 

HttpResponseNotFound 

Actua  como  HttpResponse  pero  usa  un  codigo  de 
estado  404. 

HttpResponseForbidden 

Actua  como  HttpResponse  pero  usa  un  codigo  de 
estado  403. 

HttpResponseNotAllowed 

Como  HttpResponse,  pero  usa  un  codigo  de 
estado  405.  Toma  un  unico  argumento:  una  lista 
de  los  metodos  permitidos  (ej.,  ['GET',  'POST']). 
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HttpResponseGone  Actua  como  HttpResponse  pero  usa  un  codigo  de 

estado  410. 

HttpResponseServerError  Actua  como  HttpResponse  pero  usa  un  codigo  de 

estado  500 

Tabla  G5:  Subclasses  de  HttpResponse 

Puedes,  por  supuesto,  deflnir  tus  propias  subclases  de  HttpResponse  para  permitir 
diferentes  tipos  de  respuestas  no  admitidas  por  las  clases  estandar. 

Retornar  Errores 

Retornar  codigos  de  error  HTTP  en  Django  es  facil.  Ya  hemos  mencionado  las 
subclases  HttpResponseNotFound,  HttpResponseForbidden, 

HttpResponseServerError,  y otras.  Simplemente  retorna  una  instancia  de  una  de 
estas  subclases  en  lugar  de  una  HttpResponse  normal  con  el  fin  de  significar  un  error, 
por  ejemplo: 

def  mi_vista(request): 

# ... 

if  too: 

return  HttpResponseNotFound(’<hl>Pagina  no  encontrada</hl>’) 
else: 

return  HttpResponse(’<hl>Pagina  no  encontrada</hl>’) 

Debido  a que  el  error  404  es  por  mucho  el  error  HTTP  mas  comun,  hay  una  manera 
mas  facil  de  manejarlo. 

Cuando  retornas  un  error  tal  como  HttpResponseNotFound,  eres  responsable  de 
definir  el  HTMF  de  la  pagina  de  error  resultante: 

return  HttpResponseNotFound(’<hl>Pagina  no  encontrada</hl>’) 

Por  consistencia,  y porque  es  una  buena  idea  tener  una  pagina  de  error  404 
consistente  en  todo  tu  sitio,  Django  provee  una  exception  Http404.  Si  tu  emites  una 
Http404  en  cualquier  punto  de  una  vista  de  una  funcion,  Django  la  atrapara  y 
retornara  la  pagina  de  error  estandar  de  tu  aplicacion,  junto  con  un  codigo  de  error 
HTTP  404. 

Este  es  un  ejemplo: 

from  django.http  import  Http404 

def  detalles(request,  librojd): 

try: 

p = Libro. objects. get(pk=libro_id) 
except  Libro. DoesNotExist: 
raise  Http404 

return  render_to_response(’biblioteca/detalles.htmr,  {’poll’:  p}) 

Con  el  fin  de  usar  la  exception  Http404  al  maximo,  deberias  crear  una  plantilla  que 
se  muestra  cuando  un  error  404  es  emitido.  Esta  plantilla  deberia  ser  llamada 
404.html,  y deberia  colocarse  en  el  nivel  superior  de  tu  arbol  de  plantillas. 
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Personalizar  la  Vista  404  (Not  Found) 

Cuando  tu  emites  una  exception  Http404,  Django  carga  una  vista  especial  dedicada  a 
manejar  errores  404.  Por  omision,  es  la  vista  django.views.defaults.page_not_found, 
la  cual  carga  y renderiza  la  plantilla  404.html. 

Esto  significa  que  necesitas  definir  una  plantilla  404.html  en  tu  directorio  raiz  de 
plantillas.  Esta  plantilla  sera  usada  para  todos  los  errores  404. 

Esta  vista  page_not_found  deberia  ser  suficiente  para  el  99%  de  las  aplicaciones 
Web,  pero  si  tu  quieres  reemplazar  la  vista  404,  puedes  especificar  handler404  en  tu 
URLconf,  de  la  siguiente  manera: 

from  django.conf.urls  import  url 

urlpatterns  = [ 


handler404  = 'mysite.views.my_custom_404_view' 

Detras  de  escena,  Django  determina  la  vista  404  buscando  por  handler404.  Por 
omision,  las  URLconfs  contienen  la  siguiente  linea: 

from  django.conf.urls  import  url 

Esto  se  encarga  de  establecer  handler404  en  el  modulo  actual.  Como  puedes  ver  en 
django/conf/urls/defaults.py,  handler404  esta  fijado  a 
'django.views.defaults.page_not_found'  por  omision. 

Hay  tres  cosas  para  tener  en  cuenta  sobre  las  vistas  404: 

1.  La  vista  404  es  llamada  tambien  si  Django  no  encuentra  una  coincidencia 
despues  de  verificar  toda  expresion  regular  en  la  URLconf. 

2.  Si  no  defines  tu  propia  vista  404  - y simplemente  usas  la  predeterminada,  lo 
cual  es  recomendado  - tu  aun  tienes  una  obligation:  crear  una  plantilla 
404.html  en  la  raiz  de  tu  directorio  de  plantillas.  La  vista  404  predeterminada 
usara  esa  plantilla  para  todos  los  errores  404. 

3.  Si  DEBUG  esta  establecido  a True  (en  tu  modulo  de  configuration),  entonces 
tu  vista  404  nunca  sera  usada,  y se  mostrara  en  su  lugar  el  trazado  de  pila. 
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Personalizar  la  Vista  500  (Server  Error) 

De  manera  similar,  Django  ejecuta  un  comportamiento  especial  en  el  caso  de  errores 
de  ejecucion  en  el  codigo  de  la  vista.  Si  una  vista  resulta  en  una  excepcion,  Django 
llamara,  de  manera  predeterminada,  a la  vista  django.views. defaults. server_error,  la 
cual  carga  y renderiza  la  plantilla  500.html. 

Esto  significa  que  necesitas  definir  una  plantilla  500.html  en  el  directorio  raiz  de 
plantillas.  Esta  plantilla  sera  usada  para  todos  los  errores  de  servidor. 

Esta  vista  server_ error  deheria  ser  suficiente  para  el  99%  de  las  aplicaciones  Web, 
pero  si  tu  quieres  reemplazar  la  vista,  puedes  especificar  handler500  en  tu  URLconf, 
de  la  siguiente  manera: 

from  django.conf.urls  import  url 

urlpatterns[ 

] 

handler500  = 'mysite.views.my_custom_error_view' 
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La  Portada  significa,  en  un  libro  impreso,  la  pagina  de  titulo,  mas  las  paginas 
siguientes  que  sean  necesarias  para  mantener  legiblemente  el  material  que  esta 
Licencia  requiere  en  la  portada.  Para  trabajos  en  formatos  que  no  tienen  pagina  de 
portada  como  tal,  Portada  significa  el  texto  cercano  a la  aparicion  mas  prominente 
del  titulo  del  trabajo,  precediendo  el  comienzo  del  cuerpo  del  texto.  Una  seccion 
Titulada  XYZ  significa  una  parte  del  Documento  cuyo  titulo  es  precisamente  XYZ  o 
contiene  XYZ  entre  parentesis,  a continuation  de  texto  que  traduce  XYZ  a otro  idioma 
(aqui  XYZ  se  refiere  a nombres  de  seccion  especificos  mencionados  mas  abajo,  como 
Agradecimientos,  Dedicatorias,  Aprobaciones  o Historia.  Conservar  el  Titulo  de  tal 
seccion  cuando  se  modifica  el  Documento  significa  que  permanece  una  seccion 
titulada  XYZ  segun  esta  definition. 

El  Documento  puede  incluir  Limitaciones  de  Garantia  cercanas  a la  nota  donde  se 
declara  que  al  Documento  se  le  aplica  esta  Licencia.  Se  considera  que  estas 
Limitaciones  de  Garantia  estan  incluidas,  por  referencia,  en  la  Licencia,  pero  solo  en 
cuanto  a limitaciones  de  garantia:  cualquier  otra  implication  que  estas  Limitaciones 
de  Garantia  puedan  tener  es  nula  y no  tiene  efecto  en  el  significado  de  esta  Licencia. 


2.  Copia  literal 

Usted  puede  copiar  y distribuir  el  Documento  en  cualquier  soporte,  sea  en  forma 
comercial  o no,  siempre  y cuando  esta  Licencia,  las  notas  de  copyright  y la  nota  que 
indica  que  esta  Licencia  se  aplica  al  Documento  se  reproduzcan  en  todas  las  copias  y 
que  usted  no  anada  ninguna  otra  condition  a las  expuestas  en  esta  Licencia.  Usted  no 
puede  usar  medidas  tecnicas  para  obstruir  o controlar  la  lectura  o copia  posterior  de 
las  copias  que  usted  haga  o distribuya.  Sin  embargo,  usted  puede  aceptar 
compensation  a cambio  de  las  copias.  Si  distribuye  un  numero  suficientemente 
grande  de  copias  tambien  debera  seguir  las  condiciones  de  la  seccion  3. 

Usted  tambien  puede  prestar  copias,  bajo  las  mismas  condiciones  establecidas 
anteriormente,  y puede  exhibir  copias  publicamente. 


3.  Copiado  en  cantidad 

Si  publica  copias  impresas  del  Documento  (o  copias  en  soportes  que  tengan 
normalmente  cubiertas  impresas)  que  sobrepasen  las  100,  y la  nota  de  licencia  del 
Documento  exige  Textos  de  Cubierta,  debe  incluir  las  copias  con  cubiertas  que  lleven 
en  forma  clara  y legible  todos  esos  Textos  de  Cubierta:  Textos  de  Cubierta  Delantera 
en  la  cubierta  delantera  y Textos  de  Cubierta  Trasera  en  la  cubierta  trasera.  Ambas 
cubiertas  deben  identificarlo  a Usted  clara  y legiblemente  como  editor  de  tales 
copias. 

La  cubierta  debe  mostrar  el  titulo  completo  con  todas  las  palabras  igualmente 
prominentes  y visibles.  Ademas  puede  anadir  otro  material  en  las  cubiertas.  Las 
copias  con  cambios  limitados  a las  cubiertas,  siempre  que  conserven  el  titulo  del 
Documento  y satisfagan  estas  condiciones,  pueden  considerarse  como  copias 
literales. 

Si  los  textos  requeridos  para  la  cubierta  son  muy  voluminosos  para  que  ajusten 
legiblemente,  debe  colocar  los  primeros  (tantos  como  sea  razonable  colocar)  en  la 
verdadera  cubierta  y situar  el  resto  en  paginas  adyacentes.  Si  Usted  publica  o 
distribuye  copias  Opacas  del  Documento  cuya  cantidad  exceda  las  100,  debe  incluir 
una  copia  Transparente,  que  pueda  ser  le  da  por  una  maquina,  con  cada  copia 
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Opaca,  o bien  mostrar,  en  cada  copia  Opaca,  una  direction  de  red  donde  cualquier 
usuario  de  la  misma  tenga  acceso  por  medio  de  protocolos  publicos  y estandarizados 
a una  copia  Transparente  del  Documento  completa,  sin  material  adicional.  Si  usted 
hace  uso  de  la  ultima  opcion,  debera  tomar  las  medidas  necesarias,  cuando  comience 
la  distribution  de  las  copias  Opacas  en  cantidad,  para  asegurar  que  esta  copia 
Transparente  permanecera  accesible  en  el  sitio  establecido  por  lo  menos  un  ano 
despues  de  la  ultima  vez  que  distribuya  una  copia  Opaca  de  esa  edicion  al  publico 
(directamente  o a traves  de  sus  agentes  o distribuidores). 

Se  solicita,  aunque  no  es  requisite,  que  se  ponga  en  contacto  con  los  autores  del 
Documento  antes  de  redistribuir  gran  numero  de  copias,  para  darles  la  oportunidad 
de  que  le  proporcionen  una  version  actualizada  del  Documento. 


4.  Modificaciones 

Puede  copiar  y distribuir  una  Version  Modificada  del  Documento  bajo  las 
condiciones  de  las  secciones  2 y 3 anteriores,  siempre  que  usted  libere  la  Version 
Modificada  bajo  esta  misma  Licencia,  con  la  Version  Modificada  haciendo  el  rol  del 
Documento,  por  lo  tanto  dando  licencia  de  distribucion  y modificacion  de  la  Version 
Modificada  a quienquiera  posea  una  copia  de  la  misma. 

Ademas,  debe  hacer  lo  siguiente  en  la  Version  Modificada: 

■ Usar  en  la  Portada  (y  en  las  cubiertas,  si  hay  alguna)  un  titulo  distinto  al  del 
Documento  y de  sus  versiones  anteriores  (que  deberian,  si  hay  alguna,  estar 
listadas  en  la  seccion  de  Historia  del  Documento).  Puede  usar  el  mismo  titulo 
de  versiones  anteriores  al  original  siempre  y cuando  quien  las  publico 
originalmente  otorgue  permiso. 

■ Listar  en  la  Portada,  como  autores,  una  o mas  personas  o entidades 
responsables  de  la  autoria  de  las  modificaciones  de  la  Version  Modificada, 
junto  con  por  lo  menos  cinco  de  los  autores  principales  del  Documento  (todos 
sus  autores  principales,  si  hay  menos  de  cinco),  a menos  que  le  eximan  de  tal 
requisito. 

■ Mostrar  en  la  Portada  como  editor  el  nombre  del  editor  de  la  Version 
Modificada. 

■ Conservar  todas  las  notas  de  copyright  del  Documento. 

■ Anadir  una  nota  de  copyright  apropiada  a sus  modificaciones,  adyacente  a las 
otras  notas  de  copyright. 

■ Incluir,  inmediatamente  despues  de  las  notas  de  copyright,  una  nota  de 
licencia  dando  el  permiso  para  usar  la  Version  Modificada  bajo  los  terminos 
de  esta  Licencia,  como  se  muestra  en  la  Adenda  al  final  de  este  documento. 

■ Conservar  en  esa  nota  de  licencia  el  listado  complete  de  las  Secciones 
Invariantes  y de  los  Textos  de  Cubierta  que  sean  requeridos  en  la  nota  de 
Licencia  del  Documento  original. 

■ Incluir  una  copia  sin  modificacion  de  esta  Licencia. 
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■ Conservar  la  seccion  Titulada  Historia,  conservar  su  Tltulo  y anadirle  un 
elemento  que  declare  al  menos  el  tltulo,  el  ano,  los  nuevos  autores  y el  editor 
de  la  Version  Modificada,  tal  como  figuran  en  la  Portada.  Si  no  hay  una 
seccion  Titulada  Historia  en  el  Documento,  crear  una  estableciendo  el  tltulo, 
el  ano,  los  autores  y el  editor  del  Documento,  tal  como  figuran  en  su  Portada, 
anadiendo  ademas  un  elemento  describiendo  la  Version  Modificada,  comose 
establecio  en  la  oracion  anterior. 

■ Conservar  la  direction  en  red,  si  la  hay,  dada  en  el  Documento  para  el  acceso 
publico  a una  copia  Transparente  del  mismo,  asi  como  las  otras  direcciones 
de  red  dadas  en  el  Documento  para  versiones  anteriores  en  las  que  estuviese 
basado.  Pueden  ubicarse  en  la  seccion  Historia.  Se  puede  omitir  la  ubicacion 
en  red  de  un  trabajo  que  haya  sido  publicado  por  lo  menos  cuatro  anos  antes 
que  el  Documento  mismo,  o si  el  editor  original  de  dicha  version  da  permiso. 

■ En  cualquier  seccion  Titulada  Agradecimientos  o Dedicatorias,  Conservar  el 
Tltulo  de  la  seccion  y conservar  en  ella  toda  la  sustancia  y el  tono  de  los 
agradecimientos  y/o  dedicatorias  incluidas  por  cada  contribuyente. 

■ Conservar  todas  las  Secciones  Invariantes  del  Documento,  sin  alterar  su  texto 
ni  sus  titulos.  Numeros  de  seccion  o el  equivalente  no  son  considerados  parte 
de  los  titulos  de  la  seccion. 

■ Borrar  cualquier  seccion  titulada  Aprobaciones.  Tales  secciones  no  pueden 
estar  incluidas  en  las  Versiones  Modificadas. 

■ No  cambiar  el  tltulo  de  ninguna  seccion  existente  a Aprobaciones  ni  a uno 
que  entre  en  conflicto  con  el  de  alguna  Seccion  Invariante. 

■ Conservar  todas  las  Limitaciones  de  Garantia. 

Si  la  Version  Modificada  incluye  secciones  o apendices  nuevos  que  califiquen 
como  Secciones  Secundarias  y contienen  material  no  copiado  del  Documento,  puede 
opcionalmente  designar  algunas  o todas  esas  secciones  como  invariantes.  Para 
hacerlo,  anada  sus  titulos  a la  lista  de  Secciones  Invariantes  en  la  nota  de  licencia  de 
la  Version  Modificada.  Tales  titulos  deben  ser  distintos  de  cualquier  otro  tltulo  de 
seccion. 

Puede  anadir  una  seccion  titulada  Aprobaciones,  siempre  que  contenga 
unicamente  aprobaciones  de  su  Version  Modificada  por  otras  fuentes  -por  ejemplo, 
observaciones  de  peritos  o que  el  texto  ha  sido  aprobado  por  una  organization  como 
la  definition  oficial  de  un  estandar. 

Puede  anadir  un  pasaje  de  hasta  cinco  palabras  como  Texto  de  Cubierta 
Delantera  y un  pasaje  de  hasta  25  palabras  como  Texto  de  Cubierta  Trasera  en  la 
Version  Modificada.  Una  entidad  solo  puede  anadir  (o  hacer  que  se  anada)  un  pasaje 
al  Texto  de  Cubierta  Delantera  y uno  al  de  Cubierta  Trasera.  Si  el  Documento  ya 
incluye  unos  textos  de  cubiertas  anadidos  previamente  por  usted  o por  la  misma 
entidad  que  usted  representa,  usted  no  puede  anadir  otro;  pero  puede  reemplazar  el 
anterior,  con  permiso  explicito  del  editor  que  agrego  el  texto  anterior. 

Con  esta  Licencia  ni  los  autores  ni  los  editores  del  Documento  dan  permiso  para 
usar  sus  nombres  para  publicidad  ni  para  asegurar  o implicar  aprobacion  de 
cualquier  Version  Modificada. 
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5.  Combinacion  de  documentos 

Usted  puede  combinar  el  Documento  con  otros  documentos  liberados  bajo  esta 
Licencia,  bajo  los  terminos  definidos  en  la  seccion  4 anterior  para  versiones 
modificadas,  siempre  que  incluya  en  la  combinacion  todas  las  Secciones  Invariantes 
de  todos  los  documentos  originales,  sin  modificar,  listadas  todas  como  Secciones 
Invariantes  del  trabajo  combinado  en  su  nota  de  licencia.  Asimismo  debe  incluir  la 
Limitation  de  Garantia. 

El  trabajo  combinado  necesita  contener  solamente  una  copia  de  esta  Licencia,  y 
puede  reemplazar  varias  Secciones  Invariantes  identicas  por  una  sola  copia.  Si  hay 
varias  Secciones  Invariantes  con  el  mismo  nombre  pero  con  contenidos  diferentes, 
haga  el  tltulo  de  cada  una  de  estas  secciones  unico  anadiendole  al  final  del  mismo, 
entre  parentesis,  el  nombre  del  autor  o editor  original  de  esa  seccion,  si  es  conocido, 
o si  no,  un  numero  unico.  Haga  el  mismo  ajuste  a los  titulos  de  seccion  en  la  lista  de 
Secciones  Invariantes  de  la  nota  de  licencia  del  trabajo  combinado. 

En  la  combinacion,  debe  combinar  cualquier  seccion  Titulada  Historia  de  los 
documentos  originales,  formando  una  seccion  Titulada  Historia;  de  la  misma  forma 
combine  cualquier  seccion  Titulada  Agradecimientos,  y cualquier  seccion  Titulada 
Dedicatorias.  Debe  borrar  todas  las  secciones  tituladas  Aprobaciones. 


6.  Colecciones  de  documentos 


Puede  hacer  una  coleccion  que  conste  del  Documento  y de  otros  documentos 
liberados  bajo  esta  Licencia,  y reemplazar  las  copias  individuales  de  esta  Licencia  en 
todos  los  documentos  por  una  sola  copia  que  este  incluida  en  la  coleccion,  siempre 
que  siga  las  reglas  de  esta  Licencia  para  cada  copia  literal  de  cada  uno  de  los 
documentos  en  cualquiera  de  los  demas  aspectos. 

Puede  extraer  un  solo  documento  de  una  de  tales  colecciones  y distribuirlo 
individualmente  bajo  esta  Licencia,  siempre  que  inserte  una  copia  de  esta  Licencia 
en  el  documento  extraldo,  y siga  esta  Licencia  en  todos  los  demas  aspectos  relativos  a 
la  copia  literal  de  dicho  documento. 


7.  Agregacion  con  trabajos  independientes 

Una  recopilacion  que  conste  del  Documento  o sus  derivados  y de  otros  documentos 
o trabajos  separados  e independientes,  en  cualquier  soporte  de  almacenamiento  o 
distribution,  se  denomina  un  agregado  si  el  copyright  resultante  de  la  compilation 
no  se  usa  para  limitar  los  derechos  de  los  usuarios  de  la  misma  mas  alia  de  lo  que  los 
de  los  trabajos  individuales  permiten. 

Cuando  el  Documento  se  incluye  en  un  agregado,  esta  Licencia  no  se  aplica  a 
otros  trabajos  del  agregado  que  no  sean  en  si  mismos  derivados  del  Documento. 

Si  el  requisito  de  la  seccion  3 sobre  el  Texto  de  Cubierta  es  aplicable  a estas  copias 
del  Documento  y el  Documento  es  menor  que  la  mitad  del  agregado  entero,  los 
Textos  de  Cubierta  del  Documento  pueden  colocarse  en  cubiertas  que  enmarquen 
solamente  el  Documento  dentro  del  agregado,  o el  equivalente  electronico  de  las 
cubiertas  si  el  documento  esta  en  forma  electronica. 

En  caso  contrario  deben  aparecer  en  cubiertas  impresas  enmarcando  todo  el 
agregado. 
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8.  Traduccion 

La  Traduccion  es  considerada  como  un  tipo  de  modification,  por  lo  que  usted  puede 
distribuir  traducciones  del  Documento  bajo  los  terminos  de  la  section  4.  El 
reemplazo  de  las  Secciones  Invariantes  con  traducciones  requiere  permiso  especial 
de  los  duenos  de  derecho  de  autor,  pero  usted  puede  anadir  traducciones  de  algunas 
o todas  las  Secciones  Invariantes  a las  versiones  originales  de  las  mismas. 

Puede  incluir  una  traduccion  de  esta  Licencia,  de  todas  las  notas  de  licencia  del 
documento,  asi  como  de  las  Limitaciones  de  Garantia,  siempre  que  incluya  tambien 
la  version  en  Ingles  de  esta  Licencia  y las  versiones  originales  de  las  notas  de  licencia 
y Limitaciones  de  Garantia.  En  caso  de  desacuerdo  entre  la  traduccion  y la  version 
original  en  Ingles  de  esta  Licencia,  la  nota  de  licencia  o la  limitation  de  garantia,  la 
version  original  en  Ingles  prevalecera. 

Si  una  section  del  Documento  esta  Titulada  Agradecimientos,  Dedicatorias  o 
Historia  el  requisito  (section  4)  de  Conservar  su  Titulo  (Section  1)  requerira, 
tipicamente,  cambiar  su  titulo. 


9.  Terminacion 

Usted  no  puede  copiar,  modificar,  sublicenciar  o distribuir  el  Documento  salvo  por  lo 
permitido  expresamente  por  esta  Licencia.  Cualquier  otro  intento  de  copia, 
modification,  sublicenciamiento  o distribution  del  Documento  es  nulo,  y dara  por 
terminados  automaticamente  sus  derechos  bajo  esa  Licencia.  Sin  embargo,  los 
terceros  que  hayan  recibido  copias,  o derechos,  de  usted  bajo  esta  Licencia  no  veran 
terminadas  sus  licencias,  siempre  que  permanezcan  en  total  conformidad  con  ella. 


10.  Revisiones  futuras  de  esta  licencia 

De  vez  en  cuando  la  Free  Software  Foundation  puede  publicar  versiones  nuevas  y 
revisadas  de  la  Licencia  de  Documentation  Libre  GNU.  Tales  versiones  nuevas  seran 
similares  en  espiritu  a la  presente  version,  pero  pueden  diferir  en  detalles  para 
solucionar  nuevos  problemas  o intereses.  Vea http://www.gnu.org/copyleft/. 

Cada  version  de  la  Licencia  tiene  un  numero  de  version  que  la  distingue.  Si  el 
Documento  especifica  que  se  aplica  una  version  numerada  en  particular  de  esta 
licencia  o cualquier  version  posterior,  usted  tiene  la  option  de  seguir  los  terminos  y 
condiciones  de  la  version  especificada  o cualquiera  posterior  que  haya  sido 
publicada  (no  como  borrador)  por  la  Free  Software  Foundation. 

Si  el  Documento  no  especifica  un  numero  de  version  de  esta  Licencia,  puede 
escoger  cualquier  version  que  haya  sido  publicada  (no  como  borrador)  por  la  Free 
Software  Foundation. 


11.- ADENDA:  Como  usar  esta  Licencia  en  sus  documentos 


Para  usar  esta  licencia  en  un  documento  que  usted  haya  escrito,  incluya  una  copia  de 
la  Licencia  en  el  documento  y ponga  el  siguiente  copyright  y nota  de  licencia  justo 
despues  de  la  pagina  de  titulo: 
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Copyright  (c)  AnO  SU  NOMBRE.  Se  concede  permiso  para 
copiar,  distribuir  y/o  modificar  este  documento  bajo  los 
terminos  de  la  Licencia  de  Documentacion  Libre  de  GNU, 
Version  1.2  o cualquier  otra  version  posterior  publicada 
por  la  Free  Software  Foundation;  sin  Secciones  Invariantes 
ni  Textos  de  Cubierta  Delantera  ni  Textos  de  Cubierta 
T rasera . 

Una  copia  de  la  licencia  esta  incluida  en  la  seccion 
titulada  GNU  Free  Documentation  License. 

Si  tiene  Secciones  Invariantes,  Textos  de  Cubierta  Delantera  y Textos  de  Cubierta 
Trasera,  reemplace  la  frase  sin...  Trasera  por  esto: 

siendo  las  Secciones  Invariantes  LISTE  SUS  TITULOS,  siendo 
los  Textos  de  Cubierta  Delantera  LISTAR,  y siendo  sus 
Textos  de  Cubierta  Trasera  LISTAR. 

Si  tiene  Secciones  Invariantes  sin  Textos  de  Cubierta  o cualquier  otra  combination  de 
los  tres,  mezcle  ambas  alternativas  para  adaptarse  a la  situacion. 

Si  su  documento  contiene  ejemplos  de  codigo  de  programa  no  triviales, 
recomendamos  liberar  estos  ejemplos  en  paralelo  bajo  la  licencia  de  software  libre 
que  usted  elija,  como  la  Licencia  Publica  General  de  GNU  (GNU  General  Public 
License),  para  permitir  su  uso  en  software  libre. 


